Date   

Weird bitbake generation behavior

Frans Meulenbroeks <fransmeulenbroeks@...>
 

Hi,

I share an sstate-cache with my fellow developers and I was assessing why sometimes things got rebuild even though I did not expect this.
One of the things I discovered was that we had two versions of of glog/0.3.5-r0 in sstate.
The difference was caused run.do_configure where one user had this in run.do_configure

do_configure() {
    cmake_do_configure
    # remove WORKDIR info to improve reproducibility
    if [ -f  "/workdir/build-nano/tmp/work/aarch64-sorama-linux/glog/0.3.5-r0/build/config.h" ] ; then
        sed -i 's/'$(echo /workdir/build-nano/tmp/work/aarch64-sorama-linux/glog/0.3.5-r0 | sed 's_/_\\/_g')'/../g' /workdir/build-nano/tmp/work/aarch64-sorama-linux/glog/0.3.5-r0/build/config.h
    fi
}

whereas the other just had:

do_configure() {
    cmake_do_configure
}


The weird thing is that these two builds were about a day apart, they were build on the same system with as far as I know the same metadata, the same distro, the same image etc etc
User settings should also be the same (we build under docker and I checked, we used the same version of ubuntu in the container (18.04). (Actually the containers were generated from the same Docker file and docker inspect tells me the images are identical).

Anyone an idea how this happens and where that extra snippet comes from? (I grepped for the string "reproducibility" in the bitbake folder, but that did not help)
BTW we're using dunfell

Thanks a lot, Frans


creating tarball for storing downloads; issue inheriting own-mirrors.bbclass

scott.threet@...
 

Hello,

 

I am trying to create tarballs to store yocto downloads. This is primarily to avoid old commits breaking when some random git repository changes their master branch name or something like that. I have been using this: http://embeddedguruji.blogspot.com/2019/01/storing-yocto-downloads-on-private.html, though I have seen other sources giving similar instructions.

I am having the following error (after putting the two lines at top of local.conf for my target and fixing the missing "):

ERROR: ParseError in configuration INHERITs: Could not inherit file classes/own‐mirrors.bbclass
 
 
I have pokey with path sources/poky; and in bblayers.conf I have this:
${BSPDIR}/sources/poky/meta \
We are on an old commit of poky, but that file is identical in the old commit and current head of poky. If it matters we are on zeus.
 
So from this I'm not understanding why bitbake can't find the file or if it has another error?
 
There is also supposedly an error logs at /opt/yocto/arkki-cyient-prod/bitbake-cookerdaemon.log; but my /opt folder only has a subfolder containerd.
 
Any ideas about the problem or suggestions for what to check?
 
 
Thanks for any assistance,
Scott Threet


 


Re: multilib32: libtool-cross_2.4.6.bb configure failure

Geller, Nir <nir.geller@...>
 

Hi,

 

Any help on this topic would be much appreciated.

 

Thanks,

 

Nir.

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 6:40 PM
To: yocto@...
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Executing

bitbake lib32-libtool-cross -e

Yields, among many others,

 

18513 # $TARGET_VENDOR [3 operations]

18514 #   set /home/build/tisdk/sources/oe-core/meta/conf/bitbake.conf:132

18515 #     "-oe"

18516 #   set /home/build/tisdk/sources/meta-arago/meta-arago-distro/conf/distro/include/toolchain-arm.inc:15

18517 #     ""

18518 #   override[virtclass-multilib-lib32]:set multilib_global.bbclass:159 [multilib_virtclass_handler_vendor]

18519 #     "mllib32"

18520 # pre-expansion value:

18521 #   "mllib32"

18522 TARGET_VENDOR="mllib32"

 

Later, HOST_VENDOR  = "${TARGET_VENDOR}",

And HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"

 

Ok.

 

So either these variables are calculated incorrectly, or the libtool-cross recipe needs to be fixed in order to support multilib properly.

 

Can anyone please assist?

 

Thanks,

 

Nir.

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 5:03 PM
To: Geller, Nir <nir.geller@...>; yocto@...
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

The variable SYS_HOST is expanded to armmllib32-linux-gnueabi

Shouldn’t it be expanded to arm-none-linux-gnueabihf ?

 

Thanks,

 

Nir.

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 4:41 PM
To: yocto@...
Subject: Re: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Investigating run.do_configure suggests that in the configure stage oe_runconf() is set with what seems to be wrong –host and –target values:

 --host=armmllib32-linux-gnueabi   --target=armmllib32-linux-gnueabi

 

How can I influence oe_runconf() generation and set correct values?

 

From: yocto@... <yocto@...> On Behalf Of Geller, Nir
Sent: Wednesday, August 11, 2021 12:42 PM
To: yocto@...
Subject: [yocto] multilib32: libtool-cross_2.4.6.bb configure failure

 

Hi There,

 

Following the instruction from TI

 

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Overview_Building_the_SDK.html

 

I’ve setup a yocto project for the AM64x.

 

Toolchain used is 9.2-2019.12

 

Now I need to add support for multilib32 because I have some software that can be compiled only 32 bit.

 

I added the following lines to conf/local.conf

 

# Define multilib target

require conf/multilib.conf

MULTILIBS = "multilib:lib32"

DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

 

And I am able to build a few packges with lib32- successfully, however, lib32-libtool-cross fails at the configure stage:

 

--host is set to the value armmllib32-linux-gnueabi

 

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: configure failed

ERROR: lib32-libtool-cross-2.4.6-r0 do_configure: Execution of '/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261' failed with exit code 1:

automake (GNU automake) 1.16.1

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Tom Tromey <tromey@...>

       and Alexandre Duret-Lutz <adl@...>.

AUTOV is 1.16

autoreconf: Entering directory `.'

autoreconf: configure.ac: not using Gettext

autoreconf: running: aclocal --system-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/aclocal/ --automake-acdir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal-1.16 -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ -I /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross -I m4

aclocal: warning: unknown warning category 'cross'

autoreconf: configure.ac: tracing

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoconf --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/autoheader --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/m4/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/libtool-2.4.6/tests/ --include=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/share/aclocal/ --force --warnings=cross

autoreconf: running: automake --add-missing --copy --force-missing --warnings=cross

automake: warning: unknown warning category 'cross'

autoreconf: running: gnu-configize

autoreconf: Leaving directory `.'

| NOTE: Running ../libtool-2.4.6/configure  --build=x86_64-linux                                 --host=armmllib32-linux-gnueabi                   --target=armmllib32-linux-gnueabi                         --prefix=/usr           --exec_prefix=/usr                          --bindir=/usr/bin                             --sbindir=/usr/sbin                              --libexecdir=/usr/libexec                             --datadir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share                      --sysconfdir=/etc                            --sharedstatedir=/com                                 --localstatedir=/var                             --libdir=/usr/lib                               --includedir=/usr/include                                 --oldincludedir=/usr/include                      --infodir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/info                                 --mandir=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot/usr/share/man                   --disable-silent-rules                      --disable-dependency-tracking                                --with-libtool-sysroot=/home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/lib32-recipe-sysroot

configure: loading site script /home/build/tisdk/sources/meta-openembedded/meta-networking/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/endian-little

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-common

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-32

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common-glibc

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/arm-linux

configure: loading site script /home/build/tisdk/sources/oe-core/meta/site/common

## ------------------------- ##

## Configuring libtool 2.4.6 ##

## ------------------------- ##

 

checking for GNU M4 that supports accurate traces... /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4

checking whether /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/recipe-sysroot-native/usr/bin/m4 accepts --gnu... yes

checking how m4 supports trace files... --debugfile

checking for a BSD-compatible install... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/install -c

checking whether build environment is sane... yes

checking for armmllib32-linux-gnueabi-strip... arm-none-linux-gnueabihf-strip

checking for a thread-safe mkdir -p... /home/build/tisdk/build/arago-tmp-external-arm-glibc/hosttools/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make supports nested variables... yes

checking whether make supports nested variables... (cached) yes

checking build system type... x86_64-pc-linux-gnu

checking host system type... Invalid configuration `armmllib32-linux-gnueabi': machine `armmllib32-unknown' not recognized

configure: error: /bin/bash ../libtool-2.4.6/build-aux/config.sub armmllib32-linux-gnueabi failed

WARNING: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/run.do_configure.29261:1 exit 1 from 'exit 1'

 

ERROR: Logfile of failure stored in: /home/build/tisdk/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neonmllib32-linux-gnueabi/lib32-libtool-cross/2.4.6-r0/temp/log.do_configure.29261

 

 

Manually running the configure command with –host=arm-none-linux-gnueabihf is working properly.

 

How can I fix the recipe to set –host correctly in this case?

 

Thanks a lot,

 

Nir.

 


Re: Getting bitbake error after 54% recipes are baked. #yocto #dunfell

Zoran
 

keep in mind that based upon how many vcores you allocate to VM will
determine memory pressure
as well. So if you have 2 cores perhaps 4GB is ok or maybe even 4
cores might workout ok but some bigger packages like
chromium etc. need minimal 16GB RAM to build.
This should be reflected somewhere in YOCTO documentation. Especially
for chromium.

In the section: Host HW Requirements (with some explanation why).

Zee
_______


On Tue, Aug 17, 2021 at 10:14 PM Khem Raj <raj.khem@...> wrote:

On Tue, Aug 17, 2021 at 10:36 AM <vishal.rana118@...> wrote:

Previously SDRAM was 3 GB allocated.

After changing SDRAM to 4 GB.
then trying to build/make/bitbake..
keep in mind that based upon how many vcores you allocate to VM will
determine memory pressure
as well. So if you have 2 cores perhaps 4GB is ok or maybe even 4
cores might workout ok but some bigger packages like
chromium etc. need minimal 16GB RAM to build.


getting new error i.e.
Unable to connect to bitbake server
this seems that it finds bitbake is still running and its trying to
reconnect to it. Maybe just reboot the box and try again




Re: ZFS/ZoL on Yocto

Alexandre Belloni
 

On 17/08/2021 17:52:17+0200, Manuel Wagesreither wrote:
Hello all,

I would like to know if anyone has experiences with equipping Yocto created images with ZFS support.

If I'm not mistaken, the main problems of using ZFS in linux are of legal nature. ZFS can not go into the linux kernel source tree, as it conflicts with the GPL. Hence, the linux version of ZFS called ZoL (ZFS-On-Linux) must be compiled as kernel module and recompiled at every kernel bump. On normal machines, that's a bit cumbersome, but for Yocto this shouldn't be a problem at all.

So, given the large fanbase ZFS has, I'm wondering why there are no recipes around?
I'm guessing that ZFS is not really popular on embedded systems ;)

I googled a bit, and these are the only meaningful results I found:
* https://lists.yoctoproject.org/g/yocto/message/29331
* https://gist.github.com/cveilleux/54961ccc41071e8aee8c19b69fcba78f

Regards,
Manuel



--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: Getting bitbake error after 54% recipes are baked. #yocto #dunfell

Khem Raj
 

On Tue, Aug 17, 2021 at 10:36 AM <vishal.rana118@...> wrote:

Previously SDRAM was 3 GB allocated.

After changing SDRAM to 4 GB.
then trying to build/make/bitbake..
keep in mind that based upon how many vcores you allocate to VM will
determine memory pressure
as well. So if you have 2 cores perhaps 4GB is ok or maybe even 4
cores might workout ok but some bigger packages like
chromium etc. need minimal 16GB RAM to build.


getting new error i.e.
Unable to connect to bitbake server
this seems that it finds bitbake is still running and its trying to
reconnect to it. Maybe just reboot the box and try again



Re: [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

Sinan Kaya <okaya@...>
 

On 8/17/2021 9:19 PM, Joshua Watt wrote:
I still would like to be able to static/dynamic link grpc/protobuf for
my target using the SDK.
RIght, the "mingw32" override shouldn't affect what you do with the
*target* unless your target is MinGW; I'm not sure if anyone is actually
doing that, most SDKs target Linux for ARM, Linux for AArch64, Linux for
x86, etc.

What is your target?

It's important to remember that the recipe can be built differently for
the SDK vs the target :)
ah, mine is both arm and arm64. No need to touch the recipe then.


Re: [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

Joshua Watt
 

On 8/17/21 1:15 PM, Sinan Kaya wrote:
On 8/17/2021 9:10 PM, Joshua Watt wrote:
We have use cases of both dynamic and static linkage for the
target build that we have not seen any issues with.
Are you building with "mingw32" as the target (not as the SDK), and it
works there? I wonder why it only fails for the SDK build and not the
target build? If that is truly the case, then yes I suppose it should be
the "sdkmingw32" override. The strange thing about that (and why I
thought it was incorrect) is that we have a few recipes that disable
shared libraries and/or enable static with just the "mingw32" override,
which is why I assumed it was a general limitation of MinGW, not just
the SDK. I looked through the recipes, and it does seem more apparent
that it is inconsistent, with a few recipe using "mingw32", a few using
"class-nativesdk:mingw32", and a few using "sdkmingw32".
I see two classes of problems based on my engagement with the mingw32.
Some recipes just don't build without using the static method for
the SDK and the target both. (abseil-cpp is one of them)

The nativesdk problem for grpc and protobuf is a silent failure. Even
though we are able to build the binary, we get a binary that just
doesn't work on windows. (crashes upon execution)

I still would like to be able to static/dynamic link grpc/protobuf for
my target using the SDK.
RIght, the "mingw32" override shouldn't affect what you do with the *target* unless your target is MinGW; I'm not sure if anyone is actually doing that, most SDKs target Linux for ARM, Linux for AArch64, Linux for x86, etc.

What is your target?

It's important to remember that the recipe can be built differently for the SDK vs the target :)


Anyway, please send a V4 if it needs to be changed, and I apologize for
changing it unnecessarily :)
Will do.


Re: [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

Sinan Kaya <okaya@...>
 

On 8/17/2021 9:10 PM, Joshua Watt wrote:
We have use cases of both dynamic and static linkage for the
target build that we have not seen any issues with.
Are you building with "mingw32" as the target (not as the SDK), and it
works there? I wonder why it only fails for the SDK build and not the
target build? If that is truly the case, then yes I suppose it should be
the "sdkmingw32" override. The strange thing about that (and why I
thought it was incorrect) is that we have a few recipes that disable
shared libraries and/or enable static with just the "mingw32" override,
which is why I assumed it was a general limitation of MinGW, not just
the SDK. I looked through the recipes, and it does seem more apparent
that it is inconsistent, with a few recipe using "mingw32", a few using
"class-nativesdk:mingw32", and a few using "sdkmingw32".
I see two classes of problems based on my engagement with the mingw32.
Some recipes just don't build without using the static method for
the SDK and the target both. (abseil-cpp is one of them)

The nativesdk problem for grpc and protobuf is a silent failure. Even
though we are able to build the binary, we get a binary that just
doesn't work on windows. (crashes upon execution)

I still would like to be able to static/dynamic link grpc/protobuf for
my target using the SDK.


Anyway, please send a V4 if it needs to be changed, and I apologize for
changing it unnecessarily :)
Will do.


Re: [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

Joshua Watt
 

On 8/17/21 11:29 AM, Sinan Kaya wrote:
On 8/17/2021 7:01 PM, Joshua Watt wrote:
I had to clean these up a little bit and pushed them to master-next.
Please verify that they still work for you and if not used them as a
starting point and send a V4 patchset.
Sounds good.

What do you think about this?

My reading of the problem says that the problem only happens on win32
platforms due to how DLLs initialize the heap.

We have use cases of both dynamic and static linkage for the
target build that we have not seen any issues with.
Are you building with "mingw32" as the target (not as the SDK), and it works there? I wonder why it only fails for the SDK build and not the target build? If that is truly the case, then yes I suppose it should be the "sdkmingw32" override. The strange thing about that (and why I thought it was incorrect) is that we have a few recipes that disable shared libraries and/or enable static with just the "mingw32" override, which is why I assumed it was a general limitation of MinGW, not just the SDK. I looked through the recipes, and it does seem more apparent that it is inconsistent, with a few recipe using "mingw32", a few using "class-nativesdk:mingw32", and a few using "sdkmingw32".


Anyway, please send a V4 if it needs to be changed, and I apologize for changing it unnecessarily :)


I'd like to keep target builds same supporting both static and dynamic
build but limit the tools to static link by using sdkmingw32 instead of
mingw32.

Should I send a V4?


Re: Getting bitbake error after 54% recipes are baked. #yocto #dunfell

vishal.rana118@...
 

Previously SDRAM was 3 GB allocated.

After changing SDRAM to 4 GB.
then trying to build/make/bitbake..

getting new error i.e.
Unable to connect to bitbake server


Re: Getting bitbake error after 54% recipes are baked. #yocto #dunfell

Khem Raj
 

On 8/17/21 8:38 AM, vishal.rana118@... wrote:
Hi,
I am using*ubuntu 16.04* (host) in VirtualBox.
Memory allocated to VM machine is 100+ GB.
how much DRAM is allocated.

Poky*dunfell*.
While trying to build the project fo*r x86_64.*
Steps followed as per yocto quick guide for "dunfell"
////////////////////////////////////////////////////////////////////////
after baking 54% of recipe I am getting error.
////////////////////////////////////////////////////////////////////////////////////
| /home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/as: out of memory allocating 4064 bytes after a total of 452272128 bytes
| Makefile:1117: recipe for target 'insn-emit.o' failed
| make[1]: *** [insn-emit.o] Error 2
| make[1]: *** Waiting for unfinished jobs....
| rm gcc.pod
| make[1]: Leaving directory '/home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/gcc-9.3.0/build.x86_64-poky-linux.x86_64-poky-linux/gcc'
| Makefile:4328: recipe for target 'all-gcc' failed
| make: *** [all-gcc] Error 2
| WARNING: exit code 1 from a shell command.
|
ERROR: Task (/home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1832 tasks of which 0 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
/home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:do_compile
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
////////////////////////////////////////////////////////////
looking for guidance.
Regards,


Re: Getting bitbake error after 54% recipes are baked. #yocto #dunfell

Zoran
 

> /home/vrana/Desktop/yocto_Practice/build/tmp/ \
> work/core2-64-poky-linux/gcc/9.3.0-r0/recipe-sysroot-native/ \
> usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/ \
> gcc/x86_64-poky-linux/9.3.0/as:
> out of memory allocating 4064 bytes after a total of 452272128 bytes

Looks to me that your VM ran out of SDRAM memory,
allocated for the VM, somehow.

> Memory allocated to VM machine is 100+ GB.

It is (hopefully) a VDI (Dynamic) VM disk image, NOT a SDRAM,
my best guess.

[1] You can just try to continue bitbake process, it might pass, since the
     Bitbake processes were forcefully killed, and some memory hogged
     fortunately were entirely deallocated;
[2] If [1] fails again a few times, you can try to reconfigure VMM to give
     more SDRAM to VM (have no idea what is the allocated default), it
     might help!

Zee
_______


On Tue, Aug 17, 2021 at 5:38 PM <vishal.rana118@...> wrote:

Hi,

I am using ubuntu 16.04 (host) in VirtualBox.

Memory allocated to VM machine is 100+ GB.

Poky dunfell.

While trying to build the project for x86_64.

Steps followed as per yocto quick guide for "dunfell"

////////////////////////////////////////////////////////////////////////

after baking 54% of recipe I am getting error.

////////////////////////////////////////////////////////////////////////////////////

| /home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/as: out of memory allocating 4064 bytes after a total of 452272128 bytes

| Makefile:1117: recipe for target 'insn-emit.o' failed

| make[1]: *** [insn-emit.o] Error 2

| make[1]: *** Waiting for unfinished jobs....

| rm gcc.pod

| make[1]: Leaving directory '/home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/gcc-9.3.0/build.x86_64-poky-linux.x86_64-poky-linux/gcc'

| Makefile:4328: recipe for target 'all-gcc' failed

| make: *** [all-gcc] Error 2

| WARNING: exit code 1 from a shell command.

|

ERROR: Task (/home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:do_compile) failed with exit code '1'

NOTE: Tasks Summary: Attempted 1832 tasks of which 0 didn't need to be rerun and 1 failed.

Summary: 1 task failed:

  /home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:do_compile

Summary: There were 2 ERROR messages shown, returning a non-zero exit code. 

 

////////////////////////////////////////////////////////////

looking for guidance.

 

Regards,





Re: [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

Sinan Kaya <okaya@...>
 

On 8/17/2021 7:01 PM, Joshua Watt wrote:
I had to clean these up a little bit and pushed them to master-next.
Please verify that they still work for you and if not used them as a
starting point and send a V4 patchset.
Sounds good.

What do you think about this?

My reading of the problem says that the problem only happens on win32
platforms due to how DLLs initialize the heap.

We have use cases of both dynamic and static linkage for the
target build that we have not seen any issues with.

I'd like to keep target builds same supporting both static and dynamic
build but limit the tools to static link by using sdkmingw32 instead of
mingw32.

Should I send a V4?


Re: [meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk

Joshua Watt
 

I had to clean these up a little bit and pushed them to master-next. Please verify that they still work for you and if not used them as a starting point and send a V4 patchset.

On 8/17/21 10:09 AM, Sinan Kaya wrote:
Dynamically linked protoc.exe is failing as follows:

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya <okaya@...>
---
recipes-devtools/protobuf/protobuf_%.bbappend | 1 +
1 file changed, 1 insertion(+)
create mode 100644 recipes-devtools/protobuf/protobuf_%.bbappend

diff --git a/recipes-devtools/protobuf/protobuf_%.bbappend b/recipes-devtools/protobuf/protobuf_%.bbappend
new file mode 100644
index 0000000..b53b22d
--- /dev/null
+++ b/recipes-devtools/protobuf/protobuf_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"


ZFS/ZoL on Yocto

Manuel Wagesreither
 

Hello all,

I would like to know if anyone has experiences with equipping Yocto created images with ZFS support.

If I'm not mistaken, the main problems of using ZFS in linux are of legal nature. ZFS can not go into the linux kernel source tree, as it conflicts with the GPL. Hence, the linux version of ZFS called ZoL (ZFS-On-Linux) must be compiled as kernel module and recompiled at every kernel bump. On normal machines, that's a bit cumbersome, but for Yocto this shouldn't be a problem at all.

So, given the large fanbase ZFS has, I'm wondering why there are no recipes around?

I googled a bit, and these are the only meaningful results I found:
* https://lists.yoctoproject.org/g/yocto/message/29331
* https://gist.github.com/cveilleux/54961ccc41071e8aee8c19b69fcba78f

Regards,
Manuel


Getting bitbake error after 54% recipes are baked. #yocto #dunfell

vishal.rana118@...
 

Hi,

I am using ubuntu 16.04 (host) in VirtualBox.

Memory allocated to VM machine is 100+ GB.

Poky dunfell.

While trying to build the project for x86_64.

Steps followed as per yocto quick guide for "dunfell"

////////////////////////////////////////////////////////////////////////

after baking 54% of recipe I am getting error.

////////////////////////////////////////////////////////////////////////////////////

| /home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/as: out of memory allocating 4064 bytes after a total of 452272128 bytes

| Makefile:1117: recipe for target 'insn-emit.o' failed

| make[1]: *** [insn-emit.o] Error 2

| make[1]: *** Waiting for unfinished jobs....

| rm gcc.pod

| make[1]: Leaving directory '/home/vrana/Desktop/yocto_Practice/build/tmp/work/core2-64-poky-linux/gcc/9.3.0-r0/gcc-9.3.0/build.x86_64-poky-linux.x86_64-poky-linux/gcc'

| Makefile:4328: recipe for target 'all-gcc' failed

| make: *** [all-gcc] Error 2

| WARNING: exit code 1 from a shell command.

|

ERROR: Task (/home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:do_compile) failed with exit code '1'

NOTE: Tasks Summary: Attempted 1832 tasks of which 0 didn't need to be rerun and 1 failed.

Summary: 1 task failed:

  /home/vrana/Desktop/yocto_Practice/source/poky/meta/recipes-devtools/gcc/gcc_9.3.bb:do_compile

Summary: There were 2 ERROR messages shown, returning a non-zero exit code. 

 

////////////////////////////////////////////////////////////

looking for guidance.

 

Regards,


[meta-mingw] [PATCH v3 5/5] conf/layer.conf: use BBFILES_DYNAMIC for dynamic layers

Sinan Kaya <okaya@...>
 

Add a dynamic BBFILES pattern so that patches for openembedded-layer
are conditionally applied only if meta-oe is present.

Signed-off-by: Sinan Kaya <okaya@...>
---
conf/layer.conf | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 5fefa73..d4823fc 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -3,6 +3,12 @@ BBPATH := "${BBPATH}:${LAYERDIR}"

# We have a packages directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
+BBFILES_DYNAMIC += "\
+openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/recipes-*/*/*.bb
+\
+openembedded-layer:${LAYERDIR}/dynamic-layers/openembedded-layer/recipes-*/*/*.bbappend
+\
+ "

BBFILE_COLLECTIONS += "meta-mingw"
BBFILE_PATTERN_meta-mingw := "^${LAYERDIR}/"
@@ -10,4 +16,5 @@ BBFILE_PRIORITY_meta-mingw = "8"

LAYERDEPENDS_meta-mingw = "core"

-LAYERSERIES_COMPAT_meta-mingw = "honister"
\ No newline at end of file
+LAYERSERIES_COMPAT_meta-mingw = "honister"
+
--
2.17.1


[meta-mingw] [PATCH v3 4/5] abseil-cpp: disable shared build as it is broken

Sinan Kaya <okaya@...>
 

Signed-off-by: Sinan Kaya <okaya@...>
---
recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend | 1 +
1 file changed, 1 insertion(+)
create mode 100644 recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend

diff --git a/recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend b/recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend
new file mode 100644
index 0000000..b73a8ea
--- /dev/null
+++ b/recipes-devtools/abseil-cpp/abseil-cpp_%.bbappend
@@ -0,0 +1 @@
+EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON"
--
2.17.1


[meta-mingw] [PATCH v3 3/5] grpc: static link tools when generating SDK

Sinan Kaya <okaya@...>
 

[libprotobuf ERROR google/protobuf/descriptor_database.cc:641]
File already exists in database: google/protobuf/descriptor.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1371] CHECK failed:
GeneratedDatabase()->Add(encoded_file_descriptor, size):

Switch to static linkage per upstream recommendation.

Signed-off-by: Sinan Kaya <okaya@...>
---
recipes-devtools/grpc/grpc_%.bbappend | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 recipes-devtools/grpc/grpc_%.bbappend

diff --git a/recipes-devtools/grpc/grpc_%.bbappend b/recipes-devtools/grpc/grpc_%.bbappend
new file mode 100644
index 0000000..4fcd8b9
--- /dev/null
+++ b/recipes-devtools/grpc/grpc_%.bbappend
@@ -0,0 +1,2 @@
+EXTRA_OECMAKE:remove:sdkmingw32 = "-DBUILD_SHARED_LIBS=ON"
+EXTRA_OECMAKE:append:sdkmingw32 = " -DBUILD_SHARED_LIBS=OFF"
--
2.17.1

3361 - 3380 of 57790