|
Zoran
keep in mind that based upon how many vcores you allocate to VM willThis 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:
|
|
|
|
Re: ZFS/ZoL on Yocto
Alexandre Belloni
On 17/08/2021 17:52:17+0200, Manuel Wagesreither wrote:
Hello all,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: -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
|
|
|
|
On Tue, Aug 17, 2021 at 10:36 AM <vishal.rana118@...> wrote:
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 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:
ah, mine is both arm and arm64. No need to touch the recipe then.I still would like to be able to static/dynamic link grpc/protobuf forRIght, the "mingw32" override shouldn't affect what you do with the
|
|
|
|
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: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.I see two classes of problems based on my engagement with the mingw32.We have use cases of both dynamic and static linkage for theAre you building with "mingw32" as the target (not as the SDK), and it 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 forWill 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:
I see two classes of problems based on my engagement with the mingw32.We have use cases of both dynamic and static linkage for theAre you building with "mingw32" as the target (not as the SDK), and it 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. 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: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 had to clean these up a little bit and pushed them to master-next.Sounds good. Anyway, please send a V4 if it needs to be changed, and I apologize for changing it unnecessarily :)
|
|
|
|
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
|
|
|
|
On 8/17/21 8:38 AM, vishal.rana118@... wrote:
Hi,how much DRAM is allocated. Poky*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:
|
|
|
|
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.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.
toggle quoted messageShow quoted text
On 8/17/21 10:09 AM, Sinan Kaya wrote:
Dynamically linked protoc.exe is failing as follows:
|
|
|
|
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
|
|
|
|
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_ | 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_ | 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_ 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_ 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
|
|
|
|
[meta-mingw] [PATCH v3 2/5] protobuf-c: static link 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/protobuf-c/protobuf-c_%.bbappend | 1 + 1 file changed, 1 insertion(+) create mode 100644 recipes-devtools/protobuf-c/protobuf-c_%.bbappend diff --git a/recipes-devtools/protobuf-c/protobuf-c_%.bbappend b/recipes-devtools/protobuf-c/protobuf-c_%.bbappend new file mode 100644 index 0000000..b53b22d --- /dev/null +++ b/recipes-devtools/protobuf-c/protobuf-c_%.bbappend @@ -0,0 +1 @@ +EXTRA_OECONF:append:sdkmingw32 = " --disable-shared" -- 2.17.1
|
|
|
|
[meta-mingw] [PATCH v3 1/5] protobuf: static link tools when generating sdk
Sinan Kaya <okaya@...>
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" -- 2.17.1
|
|
|
|
Re: [meta-mingw] [PATCH v2 1/3] protobuf: static link tools when generating sdk
Sinan Kaya <okaya@...>
On 8/17/2021 5:33 PM, Joshua Watt wrote:
My reading of the problem says that the problem only happens on win32+EXTRA_OECONF:append:sdkmingw32 = " --disable-shared"Apologies, this should use the :mingw32 override, since it's not 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.
|
|
|