Date   

Re: How to install rrdtool-per package?

ingemar0720@...
 

Hi Quentin
I've execute command "bitbake rrdtool -e" to checked the result and find it's been set as I expected.

This rrdtool-perl is actually required by "rpimonitor", if I execute command "bitbake rpimonitor" and it would success.
But when I execute command "bitbake mydistro", it always say "nothing provides rrdtool-perl" at "do_rootfs" stage. 

Is there any other suggestion?

 


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Joshua Watt
 

On Wed, Jul 1, 2020 at 9:47 AM MikeB <mabnhdev@gmail.com> wrote:

The rumors of my success were exaggerated. If performing a fresh build from scratch, the image build succeeds, but the populate_sdk still fails as in the original post. If I then do a 'bitbake -ccleansstate on gcc-source-9.3.0', the populate_sdk succeeds.
Ok. Are you using archiver.bbclass?


Mike

On Wed, Jul 1, 2020 at 6:45 AM MikeB <mabnhdev@gmail.com> wrote:

The combination of the https://lists.openembedded.org/g/openembedded-core/message/140161 and a 'bitbake -ccleansstate on gcc-source-9.3.0' has gotten me back on track.

Thank you all for the help!

On Tue, Jun 30, 2020 at 11:10 PM Steve Sakoman <steve@sakoman.com> wrote:

On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@lists.yoctoproject.org>
wrote:

On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@gmail.com> wrote:

I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug or just my problem. I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related
I believe I have fixed this in
https://lists.openembedded.org/g/openembedded-core/message/140161,
please try it out to make sure it solves your issue as well.
That patch came in after the 3.1.1 release, but it is present in the
dunfell branch so it will make it into 3.1.2
Doh, I'm getting ahead of myself! I was thinking of another
classes/archiver patch that Joshua sent :-)

Steve


Re: Dunfell 3.1.1 gcc-sanitizers build failure

MikeB
 

The rumors of my success were exaggerated.  If performing a fresh build from scratch, the image build succeeds, but the populate_sdk still fails as in the original post.  If I then do a 'bitbake -ccleansstate on gcc-source-9.3.0', the populate_sdk succeeds.

Mike

On Wed, Jul 1, 2020 at 6:45 AM MikeB <mabnhdev@...> wrote:
The combination of the https://lists.openembedded.org/g/openembedded-core/message/140161 and a 'bitbake -ccleansstate on gcc-source-9.3.0' has gotten me back on track.

Thank you all for the help!

On Tue, Jun 30, 2020 at 11:10 PM Steve Sakoman <steve@...> wrote:
On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@...>
wrote:
>
> On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@...> wrote:
> >
> > On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@...> wrote:
> > >
> > > On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@...> wrote:
> > > >
> > > > I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a bug or just my problem.  I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.
> > > >
> > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
> > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > > | ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
> > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
> > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > >
> > > > At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
> > >
> > > I've encountered a similar error just today when switching SDKMACHINE.
> > > Are you using archive.bbclass by any chance (INHERIT += "archive")? I
> > > just recently fixed a bug in archive.bbclass
> > > (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
> > > gcc-source raced with do_preconfigure and I'm wondering if it's
> > > related
> >
> > I believe I have fixed this in
> > https://lists.openembedded.org/g/openembedded-core/message/140161,
> > please try it out to make sure it solves your issue as well.
>
> That patch came in after the 3.1.1 release, but it is present in the
> dunfell branch so it will make it into 3.1.2

Doh, I'm getting ahead of myself! I was thinking of another
classes/archiver patch that Joshua sent :-)

Steve


Re: How to install rrdtool-per package?

Quentin Schulz
 

On Wed, Jul 01, 2020 at 07:26:00AM -0700, ingemar0720@gmail.com wrote:
On Wed, Jul 1, 2020 at 05:27 AM, "Josef Holzmayr" <holzmayr@rsi-elektrotechnik.de> wrote:


Howdy!

Am 01.07.2020 um 14:05 schrieb ingemar0720@gmail.com:

On Wed, Jul 1, 2020 at 04:46 AM, Josef Holzmayr wrote:

The correct place to do this is your DISTRO conf file.

Is this the correct way to set up it?

PACKAGECONFIG_pn-rrdtool="rrdtool rrdtool-perl"
Please see

https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#var-PACKAGECONFIG


Section "configuration file"

I've added "PACKAGECONFIG_pn-rrdtool" into my distro conf file but still get same result.

I also tried adding .bbappend but it doesn't help.

My distro conf file is in below, could you see any issue in it?

*include conf/distro/poky.conf*
*DISTRO = "rpi"*
*DISTRO_NAME = "rpi"*
*DISTRO_VERSION = "1.0"*

*PACKAGECONFIG_pn-rrdtool = "perl systemd"*

*# Use systemd as init manager*
*DISTRO_FEATURES_append = " virtualization systemd bluez5 bluetooth wifi ssh-server-openssl"*
*DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"*
*VIRTUAL-RUNTIME_init_manager = "systemd"*
*VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"*
bitbake rrdtool -e and look for the line starting with PACKAGECONFIG.
CHeck it's set to what you want, if not, look the lines above to
understand why it's not set "correctly".

Quentin


Re: How to install rrdtool-per package?

ingemar0720@...
 

On Wed, Jul 1, 2020 at 05:27 AM, "Josef Holzmayr" <holzmayr@...> wrote:
Howdy!

Am 01.07.2020 um 14:05 schrieb ingemar0720@...:
On Wed, Jul 1, 2020 at 04:46 AM, Josef Holzmayr wrote:

The correct place to do this is your DISTRO conf file.

Is this the correct way to set up it?

PACKAGECONFIG_pn-rrdtool="rrdtool rrdtool-perl"
Please see

https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#var-PACKAGECONFIG

Section "configuration file"

I've added "PACKAGECONFIG_pn-rrdtool" into my distro conf file but still get same result.

I also tried adding .bbappend but it doesn't help.

My distro conf file is in below, could you see any issue in it?


include conf/distro/poky.conf
DISTRO = "rpi"
DISTRO_NAME = "rpi"
DISTRO_VERSION = "1.0"
 
PACKAGECONFIG_pn-rrdtool = "perl systemd"
 
# Use systemd as init manager
DISTRO_FEATURES_append = " virtualization systemd bluez5 bluetooth wifi ssh-server-openssl"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"


Greetz

--
_____________________________________________________________
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


Re: ERROR: Nothing PROVIDES 'core-image-sato' #raspberrypi #yocto

Quentin Schulz
 

Hi,

On Wed, Jul 01, 2020 at 07:10:34AM -0700, Pankaj Vinadrao Joshi wrote:
Hi,
i am building an image for RPI4
You have probably added core-image-sato to DEPENDS which is incorrect.
You can't add an image recipe as a dependency.

Quentin


Re: ERROR: Nothing PROVIDES 'core-image-sato' #raspberrypi #yocto

Rudolf J Streif
 

Pankaj,

On 7/1/20 7:10 AM, Pankaj Vinadrao Joshi wrote:
Hi,
i am building an image for RPI4

Can you please provide the entire error message?

:rjs


    
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Re: How to install rrdtool-per package?

Josef Holzmayr <holzmayr@...>
 

Howdy!

Am 01.07.2020 um 14:05 schrieb ingemar0720@gmail.com:
On Wed, Jul 1, 2020 at 04:46 AM, Josef Holzmayr wrote:
The correct place to do this is your DISTRO conf file.
Is this the correct way to set up it?
PACKAGECONFIG_pn-rrdtool="rrdtool rrdtool-perl"
Please see

https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#var-PACKAGECONFIG

Section "configuration file"

Greetz

--
_____________________________________________________________
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


Re: How to install rrdtool-per package?

ingemar0720@...
 

On Wed, Jul 1, 2020 at 04:46 AM, Josef Holzmayr wrote:
The correct place to do this is your DISTRO conf file.

Is this the correct way to set up it?

PACKAGECONFIG_pn-rrdtool="rrdtool rrdtool-perl"

 


Re: How to install rrdtool-per package?

Josef Holzmayr <holzmayr@...>
 

Howdy!

Am 01.07.2020 um 13:04 schrieb ingemar0720@gmail.com:
Hello Josef
Thanks for you reply!
From your link, it seems rrdtool recipe already give an alias as `rrdtool-perl`, is it correct?
Exactly. If activated, then the rrdtool recipe already procides the rrdtool-perl package.

Then shall I add PACKAGECONFIG in .bbappend file for rrdtool? Or i shall add in my own recipe?
The correct place to do this is your DISTRO conf file.

Greetz

--
_____________________________________________________________
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


Re: How to install rrdtool-per package?

ingemar0720@...
 

Hello Josef

Thanks for you reply!
From your link, it seems rrdtool recipe already give an alias as `rrdtool-perl`, is it correct?

Then shall I add PACKAGECONFIG in .bbappend file for rrdtool? Or i shall add in my own recipe?


Re: Dunfell 3.1.1 gcc-sanitizers build failure

MikeB
 

The combination of the https://lists.openembedded.org/g/openembedded-core/message/140161 and a 'bitbake -ccleansstate on gcc-source-9.3.0' has gotten me back on track.

Thank you all for the help!

On Tue, Jun 30, 2020 at 11:10 PM Steve Sakoman <steve@...> wrote:
On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@...>
wrote:
>
> On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@...> wrote:
> >
> > On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@...> wrote:
> > >
> > > On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@...> wrote:
> > > >
> > > > I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a bug or just my problem.  I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.
> > > >
> > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
> > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > > | ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
> > > > | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
> > > > | WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > >
> > > > At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
> > >
> > > I've encountered a similar error just today when switching SDKMACHINE.
> > > Are you using archive.bbclass by any chance (INHERIT += "archive")? I
> > > just recently fixed a bug in archive.bbclass
> > > (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
> > > gcc-source raced with do_preconfigure and I'm wondering if it's
> > > related
> >
> > I believe I have fixed this in
> > https://lists.openembedded.org/g/openembedded-core/message/140161,
> > please try it out to make sure it solves your issue as well.
>
> That patch came in after the 3.1.1 release, but it is present in the
> dunfell branch so it will make it into 3.1.2

Doh, I'm getting ahead of myself! I was thinking of another
classes/archiver patch that Joshua sent :-)

Steve


Re: How to install rrdtool-per package?

Josef Holzmayr <holzmayr@...>
 

Howdy!

Looks very much like you'll need to set up PACKAGECONFIG of rrdtool, then it should provide rrdtool-perl.

See also: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/rrdtool/rrdtool_1.7.2.bb?h=master#n104

Greetz

Am 01.07.2020 um 11:50 schrieb ingemar0720@gmail.com:

My Yocto build failed and it seems to be looking for "rrdtool-perl" package. I've added package "rrdtool" into my "INSTALL_APPEND" variable but it still fail. The logs is in below. Could someone helped me to find the correct recipe to install it?
"""
repo: using cache for: oe-repo
not found other for:
not found modules for:
not found deltainfo for:
not found updateinfo for:
oe-repo: using metadata from Wed 01 Jul 2020 09:34:21 AM UTC.
Last metadata expiration check: 0:00:01 ago on Wed 01 Jul 2020 09:34:22 AM UTC.
No module defaults found
--> Starting dependency resolution
--> Finished dependency resolution
Error:
 Problem: conflicting requests
  - nothing provides rrdtool-perl needed by rpimonitor-2.13-r0.arm1176jzfshf_vfp
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
ERROR: Logfile of failure stored in: /home/ingemar/yocto/sdk/build/tmp/work/raspberrypi0_wifi-poky-linux-gnueabi/rpi-image/1.0-r0/temp/log.do_rootfs.27003
ERROR: Task (/home/ingemar/yocto/sdk/build/../build/meta-rpi/recipes-core/images/rpi-image.bb:do_rootfs) failed with exit code '1'
"""
--
_____________________________________________________________
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


How to install rrdtool-per package?

ingemar0720@...
 

My Yocto build failed and it seems to be looking for "rrdtool-perl" package. I've added package "rrdtool" into my "INSTALL_APPEND" variable but it still fail. The logs is in below. Could someone helped me to find the correct recipe to install it?

 

"""

repo: using cache for: oe-repo

not found other for:

not found modules for:

not found deltainfo for:

not found updateinfo for:

oe-repo: using metadata from Wed 01 Jul 2020 09:34:21 AM UTC.

Last metadata expiration check: 0:00:01 ago on Wed 01 Jul 2020 09:34:22 AM UTC.

No module defaults found

--> Starting dependency resolution

--> Finished dependency resolution

Error:

 Problem: conflicting requests

  - nothing provides rrdtool-perl needed by rpimonitor-2.13-r0.arm1176jzfshf_vfp

(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

 

ERROR: Logfile of failure stored in: /home/ingemar/yocto/sdk/build/tmp/work/raspberrypi0_wifi-poky-linux-gnueabi/rpi-image/1.0-r0/temp/log.do_rootfs.27003

ERROR: Task (/home/ingemar/yocto/sdk/build/../build/meta-rpi/recipes-core/images/rpi-image.bb:do_rootfs) failed with exit code '1'

"""


Re: Need help understanding #devtool flow to library #devtool

tobies@...
 

Hi Quentin

That was indeed the problem. The reason that my code was not working as expected was not in the devtool flow but in my code :-).

So now on to debugging my real problem.

Thanks a lot!

Stephan


Re: License reporting for golang (and rust)

Robert Berger
 

Hi,

My comments are in-line

On 30/06/2020 14:37, Irving ST wrote:
Hi,
For anyone else having the same problem, here's what I eventually did
for my go stuff:
I created a bbclass containing a task that gets inherited by all
packages, but the task only does some work when it detects that it is
inherited by a golang recipe.
The task basically sets up GOPATH and calls
https://github.com/rancher/trash - this tool populates all the source
dependencies and generate a trash.lock file in the repository.
Then I used https://github.com/pivotal/LicenseFinder to generate a
json report that can be postprocessed with python.
Is your work available somewhere in the public? I would like to give it a try with dunfell 3.1.1 and influxdb.[1] Also it would be interesting what happens if you include a prebuilt go executable[2].

[1] https://gitlab.com/meta-layers/meta-tig/-/blob/master/recipes-from-source/github.com-influxdata-influxdb/github.com-influxdata-influxdb_1.8.0.bb (from khem and slightly hacked)

[2] https://gitlab.com/meta-layers/meta-tig/-/blob/master/recipes-prebuilt/influxdb/influxdb_1.8.0.bb

To me it seems that Go used the vendor directory approach in the past,
and there are multiple tools that can be used for this; and nowadays
go seems to have switched to a different approach called go modules.
It looks like master and dunfell 3.1.1 support go modules now.[3][4]

[3] http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=7892a056f7e03e9c086148f8f027bd1cebf2aa68
[4] http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=ce277ec45f1f241b1eb17ea6999dbe5a718b898a

Now we have both go dep and go modules support ;)

With this multiple tools and methods of managing dependencies, I am
not sure whether it is feasible to integrate this in Yocto at all -
though I think I have seen mailing list posts on meta-virtualization
adding vendor information to their recipes, so maybe some progress is
happening there.
Currently arm 32 Golang support is broken in meta-virt (docker), but I am confident it's going to be fixed soon.[5]

[5] https://lists.yoctoproject.org/g/meta-virtualization/message/5488?p=,,,20,0,0,0::Created,,docker,20,2,0,75127700

Best regards,
Irving Tjiptowarsono
Regards,

Robert


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Steve Sakoman
 

On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@lists.yoctoproject.org>
wrote:

On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@gmail.com> wrote:

I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug or just my problem. I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related
I believe I have fixed this in
https://lists.openembedded.org/g/openembedded-core/message/140161,
please try it out to make sure it solves your issue as well.
That patch came in after the 3.1.1 release, but it is present in the
dunfell branch so it will make it into 3.1.2
Doh, I'm getting ahead of myself! I was thinking of another
classes/archiver patch that Joshua sent :-)

Steve


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Steve Sakoman
 

On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt <JPEWhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@gmail.com> wrote:

I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug or just my problem. I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related
I believe I have fixed this in
https://lists.openembedded.org/g/openembedded-core/message/140161,
please try it out to make sure it solves your issue as well.
That patch came in after the 3.1.1 release, but it is present in the
dunfell branch so it will make it into 3.1.2

Steve


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Joshua Watt
 

On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt <jpewhacker@gmail.com> wrote:

On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@gmail.com> wrote:

I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug or just my problem. I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related
I believe I have fixed this in
https://lists.openembedded.org/g/openembedded-core/message/140161,
please try it out to make sure it solves your issue as well.



I've attached the full error log. Any troubleshooting advice would be appreciated.


Re: Dunfell 3.1.1 gcc-sanitizers build failure

Joshua Watt
 

On Tue, Jun 30, 2020 at 4:56 PM MikeB <mabnhdev@gmail.com> wrote:

I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a bug or just my problem. I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK.

| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' failed with exit code 1:
| cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: No such file or directory
| WARNING: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work around - and got the same failure.
I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related


I've attached the full error log. Any troubleshooting advice would be appreciated.

4101 - 4120 of 53906