Message ID | 20220809075704.86472-1-ardeleanalex@gmail.com |
---|---|
Headers | show |
Series | package/nodejs: rework cross-building | expand |
Hello Alexandru, First of all, thanks a lot for your work on NodeJS. It is obviously a complex package, which has already seen quite a lot of effort, so we need to be careful when changing it. On Tue, 9 Aug 2022 10:56:51 +0300 Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > I tried to build nodejs from Buildroot master, but I couldn't. > It could be that I did not setup something properly with regards to the > 'v8-qemu-wrapper' stuff. I kept getting execution errors, when trying to > run the nodejs build-tools scripts (see details in the patches). > Either the host-qemu stuff isn't working correctly, or it needs some extra > setup. I will give a test to your patch series and report back, but I'm fearing that PATCH 03/18 will break the build. > That eventually sent me down the rabbit-hole of trying to get nodejs to > build for ARM64 (where I wanted it). It seems that nodejs cross-building > can be done via their own infra-structure, which isn't perfect, but it > seems usable; and it also looks like a good idea. > > Using their cross-building stuff, has some issues/considerations: > * it's easiest when building a 32/64-bit target on a (same bit-width) > 32/64-bit host; the host-{c-ares,icu,libuv,zlib} tools can be used > for nodejs' host tools (in their cross-build infrastructure/tools) > * when building a 32-bit target on a 64-bit host, the nodejs cross-building > logic will add the -m32 CFLAG, which will mean that the > host-{c-ares,icu,libuv,zlib} tools will be unusable (they got compiled > for 64-bit and are un-linkable to 32-bit binaries) > This requires that the user install on their system the > host-{c-ares,icu,libuv,zlib} 32 bit versions. I suspect that the > BR2_HOSTARCH_NEEDS_IA32_{LIBS,COMPILER} symbols are intented for this > * I haven't tried to build 64-bit targets on 32-bit hosts, though I'd > guess this is a rare corner case. No, unfortunately it is not. A solution that doesn't support building a 64-bit target on a 32-bit host is not going to be acceptable for Buildroot at this point I'm afraid. I will try to have a look in more details, even though I must say I'm pretty hermetic to the overall NodeJS build system :-/ Best regards, Thomas
On Tue, Aug 9, 2022 at 2:42 PM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello Alexandru, > > First of all, thanks a lot for your work on NodeJS. It is obviously a > complex package, which has already seen quite a lot of effort, so we > need to be careful when changing it. > > On Tue, 9 Aug 2022 10:56:51 +0300 > Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > > > I tried to build nodejs from Buildroot master, but I couldn't. > > It could be that I did not setup something properly with regards to the > > 'v8-qemu-wrapper' stuff. I kept getting execution errors, when trying to > > run the nodejs build-tools scripts (see details in the patches). > > Either the host-qemu stuff isn't working correctly, or it needs some extra > > setup. > > I will give a test to your patch series and report back, but I'm > fearing that PATCH 03/18 will break the build. > > > That eventually sent me down the rabbit-hole of trying to get nodejs to > > build for ARM64 (where I wanted it). It seems that nodejs cross-building > > can be done via their own infra-structure, which isn't perfect, but it > > seems usable; and it also looks like a good idea. > > > > Using their cross-building stuff, has some issues/considerations: > > * it's easiest when building a 32/64-bit target on a (same bit-width) > > 32/64-bit host; the host-{c-ares,icu,libuv,zlib} tools can be used > > for nodejs' host tools (in their cross-build infrastructure/tools) > > * when building a 32-bit target on a 64-bit host, the nodejs cross-building > > logic will add the -m32 CFLAG, which will mean that the > > host-{c-ares,icu,libuv,zlib} tools will be unusable (they got compiled > > for 64-bit and are un-linkable to 32-bit binaries) > > This requires that the user install on their system the > > host-{c-ares,icu,libuv,zlib} 32 bit versions. I suspect that the > > BR2_HOSTARCH_NEEDS_IA32_{LIBS,COMPILER} symbols are intented for this > > * I haven't tried to build 64-bit targets on 32-bit hosts, though I'd > > guess this is a rare corner case. > > No, unfortunately it is not. A solution that doesn't support building a > 64-bit target on a 32-bit host is not going to be acceptable for > Buildroot at this point I'm afraid. There may be a chance that this could automagically work (64 bit target to 32 bit host). I did not test it. I will try to make some time for testing it in a 32-bit x86 docker image. I figured this may be unacceptable. The least I was hoping to get here, is someone to tell me what I am doing wrong with that v8-qemu-wrapper stuff. > > I will try to have a look in more details, even though I must say I'm > pretty hermetic to the overall NodeJS build system :-/ > > Best regards, > > Thomas > -- > Thomas Petazzoni, co-owner and CEO, Bootlin > Embedded Linux and Kernel engineering and training > https://bootlin.com
Hello, On Tue, 9 Aug 2022 10:56:51 +0300 Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > I tried to build nodejs from Buildroot master, but I couldn't. > It could be that I did not setup something properly with regards to the > 'v8-qemu-wrapper' stuff. I kept getting execution errors, when trying to > run the nodejs build-tools scripts (see details in the patches). > Either the host-qemu stuff isn't working correctly, or it needs some extra > setup. > > That eventually sent me down the rabbit-hole of trying to get nodejs to > build for ARM64 (where I wanted it). It seems that nodejs cross-building > can be done via their own infra-structure, which isn't perfect, but it > seems usable; and it also looks like a good idea. You could also have a look at the OpenEmbedded packaging of NodeJS: https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/nodejs?h=kirkstone The idea and some of the logic for the Qemu wrapper comes from OpenEmbedded. Thomas
On Thu, Aug 11, 2022 at 12:23 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello, > > On Tue, 9 Aug 2022 10:56:51 +0300 > Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > > > I tried to build nodejs from Buildroot master, but I couldn't. > > It could be that I did not setup something properly with regards to the > > 'v8-qemu-wrapper' stuff. I kept getting execution errors, when trying to > > run the nodejs build-tools scripts (see details in the patches). > > Either the host-qemu stuff isn't working correctly, or it needs some extra > > setup. > > > > That eventually sent me down the rabbit-hole of trying to get nodejs to > > build for ARM64 (where I wanted it). It seems that nodejs cross-building > > can be done via their own infra-structure, which isn't perfect, but it > > seems usable; and it also looks like a good idea. > > You could also have a look at the OpenEmbedded packaging of NodeJS: > > https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/nodejs?h=kirkstone > > The idea and some of the logic for the Qemu wrapper comes from > OpenEmbedded. I'll take a look. Thanks for the hint. At this point, I am also curious if we could get away without this wrapper. Maybe we're entering a point where nodejs' build system is becoming good/mature enough to not have to use QEMU. Alexandru > > Thomas > -- > Thomas Petazzoni, co-owner and CEO, Bootlin > Embedded Linux and Kernel engineering and training > https://bootlin.com
Hello Alexandru, On Tue, 9 Aug 2022 10:56:51 +0300 Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > Alexandru Ardelean (13): > package/libuv: add host-build > package/nghttp2: add host-build > nodejs: remove v8-qemu-wrapper stuff > nodejs: fix 'Duplicate v8 target errors when cross-compiling' error > package/nodejs: add host-{c-ares,libuv,nghttp2} to deps > package/nodejs: provide {CC,CXX,CFLAGS,CXXFLAGS,LDFLAGS}_host env vars > to target-build > package/nodejs: don't install nodejs host-tools > package/nodejs: rename LDFLAGS.host -> LDFLAGS opt > package/nodejs: impose dep on ia32 libs/compiler if target arch not 64 > bits > package/nodejs: add host-zlib depedency to target package > package/nodejs: fix ARM build with VFP3 instruction > package/nodejs: add a hack to cross-compile 32-bit targets on x64 > hosts > package/nodejs: build host-nodejs only if we're installing modules > with NPM So I finally took some time to look into this, and managed to get NodeJS to build, but keeping the Qemu logic. Here is what I have pushed to the Buildroot Git repo: https://gitlab.com/buildroot.org/buildroot/-/commit/f85e2cfc6e587d50b86f49b28469eae58a2ea2c7 Just renumbering an existing patch https://gitlab.com/buildroot.org/buildroot/-/commit/5708c5b04f09f49a99c2c9d7a1894d24bce6a3e7 Your patch to fix the duplicate v8 target error, just slightly improved by me. https://gitlab.com/buildroot.org/buildroot/-/commit/cf0ddc89705af989393b1601bbf57d567a9a1b13 A patch from me which is fixing the issue with the Qemu approach. Basically, since the bump from 14.x to 16.x, one call to a tool that should be run under Qemu was not done through the wrapper, causing the build failure. With this fixed, NodeJS builds just fine with the current approach. Even though I dislike having to build Qemu, it is what OpenEmbedded is also doing to build NodeJS, and we don't have much choice as we need those tools to have the same bitness as the target. https://gitlab.com/buildroot.org/buildroot/-/commit/ec5589611ad79664bc5bf238cc786a65458f3c93 Your patch to not install the extra tools of host-nodejs, as they are no longer needed: we use the target tools, and run them under Qemu. https://gitlab.com/buildroot.org/buildroot/-/commit/1facb09b94bf806b301868539185c0ff9ddffee2 Your patch to no longer build host-nodejs as a dependency of nodejs, unless some extra NPM modules need to be installed, in which case npm is needed. So here, NodeJS now builds/runs fine. Could you check on your side if that also solves your problems? Best regards, Thomas
On Sun, Sep 25, 2022 at 11:27 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello Alexandru, > > On Tue, 9 Aug 2022 10:56:51 +0300 > Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > > > Alexandru Ardelean (13): > > package/libuv: add host-build > > package/nghttp2: add host-build > > nodejs: remove v8-qemu-wrapper stuff > > nodejs: fix 'Duplicate v8 target errors when cross-compiling' error > > package/nodejs: add host-{c-ares,libuv,nghttp2} to deps > > package/nodejs: provide {CC,CXX,CFLAGS,CXXFLAGS,LDFLAGS}_host env vars > > to target-build > > package/nodejs: don't install nodejs host-tools > > package/nodejs: rename LDFLAGS.host -> LDFLAGS opt > > package/nodejs: impose dep on ia32 libs/compiler if target arch not 64 > > bits > > package/nodejs: add host-zlib depedency to target package > > package/nodejs: fix ARM build with VFP3 instruction > > package/nodejs: add a hack to cross-compile 32-bit targets on x64 > > hosts > > package/nodejs: build host-nodejs only if we're installing modules > > with NPM > > So I finally took some time to look into this, and managed to get > NodeJS to build, but keeping the Qemu logic. Here is what I have pushed > to the Buildroot Git repo: > > https://gitlab.com/buildroot.org/buildroot/-/commit/f85e2cfc6e587d50b86f49b28469eae58a2ea2c7 > > Just renumbering an existing patch > > https://gitlab.com/buildroot.org/buildroot/-/commit/5708c5b04f09f49a99c2c9d7a1894d24bce6a3e7 > > Your patch to fix the duplicate v8 target error, just slightly > improved by me. > > https://gitlab.com/buildroot.org/buildroot/-/commit/cf0ddc89705af989393b1601bbf57d567a9a1b13 > > A patch from me which is fixing the issue with the Qemu approach. > Basically, since the bump from 14.x to 16.x, one call to a tool that > should be run under Qemu was not done through the wrapper, causing > the build failure. With this fixed, NodeJS builds just fine with the > current approach. > > Even though I dislike having to build Qemu, it is what OpenEmbedded > is also doing to build NodeJS, and we don't have much choice as we > need those tools to have the same bitness as the target. > > https://gitlab.com/buildroot.org/buildroot/-/commit/ec5589611ad79664bc5bf238cc786a65458f3c93 > > Your patch to not install the extra tools of host-nodejs, as they are > no longer needed: we use the target tools, and run them under Qemu. > > https://gitlab.com/buildroot.org/buildroot/-/commit/1facb09b94bf806b301868539185c0ff9ddffee2 > > Your patch to no longer build host-nodejs as a dependency of nodejs, > unless some extra NPM modules need to be installed, in which case npm > is needed. > > So here, NodeJS now builds/runs fine. Could you check on your side if > that also solves your problems? Hey, I'll take a look. Apologies for going silent on this. I need to scale down my work maybe. Funny story (or... maybe not so funny), the project switched to AOSP, which is ¯\_(ツ)_/¯ (new to me). In the old context (when we were using BR), we were basing some work on top of RPi4. And when I sent the initial set upstream, I was testing/validating with RPi4 (32 & 64 bit builds) directly on the BR upstream/master tree. i.e. i was using "raspberrypi4{_64}_defconfig" + manually enabling nodejs (and using the external Linaro ARM toolchains to gain some speed). I'll do some builds with these 2 configurations and come back. Thanks Alexandru > > Best regards, > > Thomas > -- > Thomas Petazzoni, co-owner and CEO, Bootlin > Embedded Linux and Kernel engineering and training > https://bootlin.com
On Sun, Sep 25, 2022 at 6:17 PM Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > > On Sun, Sep 25, 2022 at 11:27 AM Thomas Petazzoni > <thomas.petazzoni@bootlin.com> wrote: > > > > Hello Alexandru, > > > > On Tue, 9 Aug 2022 10:56:51 +0300 > > Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > > > > > Alexandru Ardelean (13): > > > package/libuv: add host-build > > > package/nghttp2: add host-build > > > nodejs: remove v8-qemu-wrapper stuff > > > nodejs: fix 'Duplicate v8 target errors when cross-compiling' error > > > package/nodejs: add host-{c-ares,libuv,nghttp2} to deps > > > package/nodejs: provide {CC,CXX,CFLAGS,CXXFLAGS,LDFLAGS}_host env vars > > > to target-build > > > package/nodejs: don't install nodejs host-tools > > > package/nodejs: rename LDFLAGS.host -> LDFLAGS opt > > > package/nodejs: impose dep on ia32 libs/compiler if target arch not 64 > > > bits > > > package/nodejs: add host-zlib depedency to target package > > > package/nodejs: fix ARM build with VFP3 instruction > > > package/nodejs: add a hack to cross-compile 32-bit targets on x64 > > > hosts > > > package/nodejs: build host-nodejs only if we're installing modules > > > with NPM > > > > So I finally took some time to look into this, and managed to get > > NodeJS to build, but keeping the Qemu logic. Here is what I have pushed > > to the Buildroot Git repo: > > > > https://gitlab.com/buildroot.org/buildroot/-/commit/f85e2cfc6e587d50b86f49b28469eae58a2ea2c7 > > > > Just renumbering an existing patch > > > > https://gitlab.com/buildroot.org/buildroot/-/commit/5708c5b04f09f49a99c2c9d7a1894d24bce6a3e7 > > > > Your patch to fix the duplicate v8 target error, just slightly > > improved by me. > > > > https://gitlab.com/buildroot.org/buildroot/-/commit/cf0ddc89705af989393b1601bbf57d567a9a1b13 > > > > A patch from me which is fixing the issue with the Qemu approach. > > Basically, since the bump from 14.x to 16.x, one call to a tool that > > should be run under Qemu was not done through the wrapper, causing > > the build failure. With this fixed, NodeJS builds just fine with the > > current approach. > > > > Even though I dislike having to build Qemu, it is what OpenEmbedded > > is also doing to build NodeJS, and we don't have much choice as we > > need those tools to have the same bitness as the target. > > > > https://gitlab.com/buildroot.org/buildroot/-/commit/ec5589611ad79664bc5bf238cc786a65458f3c93 > > > > Your patch to not install the extra tools of host-nodejs, as they are > > no longer needed: we use the target tools, and run them under Qemu. > > > > https://gitlab.com/buildroot.org/buildroot/-/commit/1facb09b94bf806b301868539185c0ff9ddffee2 > > > > Your patch to no longer build host-nodejs as a dependency of nodejs, > > unless some extra NPM modules need to be installed, in which case npm > > is needed. > > > > So here, NodeJS now builds/runs fine. Could you check on your side if > > that also solves your problems? > > Hey, > > I'll take a look. > Apologies for going silent on this. I need to scale down my work maybe. > > Funny story (or... maybe not so funny), the project switched to AOSP, > which is ¯\_(ツ)_/¯ (new to me). > > In the old context (when we were using BR), we were basing some work > on top of RPi4. > And when I sent the initial set upstream, I was testing/validating > with RPi4 (32 & 64 bit builds) directly on the BR upstream/master > tree. > i.e. i was using "raspberrypi4{_64}_defconfig" + manually enabling > nodejs (and using the external Linaro ARM toolchains to gain some > speed). > > I'll do some builds with these 2 configurations and come back. So, still fails on my side. I'm using Ubuntu 22.04 Steps to reproduce: 1. make raspberrypi4_defconfig ( or raspberrypi4_64_defconfig ) 2 make menuconfig # to enable nodejs (or external toolchain) 3. make V=s -j12 4. fail I initially got tried with ARM{64} external toolchains I decided to give it a try with BR's ARM toolchain (I did not try ARM64 with BR's toolchain) Seems the /workdir/buildroot/output/host/bin/qemu-arm{64} files aren't present. [1] https://gitlab.com/buildroot.org/buildroot/-/commit/1facb09b94bf806b301868539185c0ff9ddffee2 Luckily with patch [1] I get the errors way sooner (than waiting for host-nodejs to be built) [1] ARM64 (with external toolchain) did this: [5/2481] ACTION generate_bytecode_builtins_list: generate_bytecode_builtins_list_action_3931b343a4cb0bd98da4e581f6ce90fe FAILED: obj/gen/generate-bytecode-output-root/builtins-generated/bytecodes-builtins-list.h cd ../../tools/v8_gypfiles; python ../../deps/v8/tools/run.py ../../out/Release/v8-qemu-wrapper ../../out/Release/bytecode_builtins_list_generator ../../out/Release/obj/gen/generate-bytecode-output-root/builtins-generated/bytecodes-builtins-list.h ../../out/Release/v8-qemu-wrapper: 5: exec: /home/aardelean/work/upstream/buildroot/output/host/bin/qemu-aarch64: not found Return code is 127 [6/2481] ACTION(host) generate_bytecode_builtins_list: generate_bytecode_builtins_list_action_33373b52e07ceb63cab644698db39dd6 FAILED: obj.host/gen/generate-bytecode-output-root/builtins-generated/bytecodes-builtins-list.h cd ../../tools/v8_gypfiles; python ../../deps/v8/tools/run.py ../../out/Release/v8-qemu-wrapper ../../out/Release/bytecode_builtins_list_generator ../../out/Release/obj.host/gen/generate-bytecode-output-root/builtins-generated/bytecodes-builtins-list.h ../../out/Release/v8-qemu-wrapper: 5: exec: /home/aardelean/work/upstream/buildroot/output/host/bin/qemu-aarch64: not found Return code is 127 [22/2481] CXX obj/deps/googletest/src/gtest.gtest.o ninja: build stopped: subcommand failed. make[2]: *** [Makefile:127: node] Error 1 make[1]: *** [package/pkg-generic.mk:293: /home/aardelean/work/upstream/buildroot/output/build/nodejs-16.16.0/.stamp_built] Error 2 make: *** [Makefile:84: _all] Error 2 [2] ARM64 (with external toolchain) did this: | ^~~~~~~~~~~ In file included from /home/aardelean/work/upstream/buildroot/output/host/opt/ext-toolchain/arm-none-linux-gnueabihf/include/c++/10.3.1/vector:72, from /home/aardelean/work/upstream/buildroot/output/host/opt/ext-toolchain/arm-none-linux-gnueabihf/include/c++/10.3.1/queue:61, from ../../deps/v8/src/libplatform/default-foreground-task-runner.h:9, from ../../deps/v8/src/libplatform/default-foreground-task-runner.cc:5: /home/aardelean/work/upstream/buildroot/output/host/opt/ext-toolchain/arm-none-linux-gnueabihf/include/c++/10.3.1/bits/vector.tcc: In member function ‘void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with _Args = {v8::platform::DefaultForegroundTaskRunner::DelayedEntry}; _Tp = v8::platform::DefaultForegroundTaskRunner::DelayedEntry; _Alloc = std::allocator<v8::platform::DefaultForegroundTaskRunner::DelayedEntry>]’: /home/aardelean/work/upstream/buildroot/output/host/opt/ext-toolchain/arm-none-linux-gnueabihf/include/c++/10.3.1/bits/vector.tcc:426:7: note: parameter passing for argument of type ‘std::vector<v8::platform::DefaultForegroundTaskRunner::DelayedEntry>::iterator’ changed in GCC 7.1 426 | vector<_Tp, _Alloc>:: | ^~~~~~~~~~~~~~~~~~~ /home/aardelean/work/upstream/buildroot/output/host/opt/ext-toolchain/arm-none-linux-gnueabihf/include/c++/10.3.1/bits/vector.tcc: In function ‘void v8::platform::DefaultForegroundTaskRunner::PostDelayedTaskLocked(std::unique_ptr<v8::Task>, double, v8::platform::DefaultForegroundTaskRunner::Nestability, const MutexGuard&)’: /home/aardelean/work/upstream/buildroot/output/host/opt/ext-toolchain/arm-none-linux-gnueabihf/include/c++/10.3.1/bits/vector.tcc:121:21: note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator<v8::platform::DefaultForegroundTaskRunner::DelayedEntry*, std::vector<v8::platform::DefaultForegroundTaskRunner::DelayedEntry> >’ changed in GCC 7.1 121 | _M_realloc_insert(end(), std::forward<_Args>(__args)...); | ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [145/2633] ACTION(host) generate_bytecode_builtins_list: generate_bytecode_builtins_list_action_33373b52e07ceb63cab644698db39dd6 FAILED: obj.host/gen/generate-bytecode-output-root/builtins-generated/bytecodes-builtins-list.h cd ../../tools/v8_gypfiles; python ../../deps/v8/tools/run.py ../../out/Release/v8-qemu-wrapper ../../out/Release/bytecode_builtins_list_generator ../../out/Release/obj.host/gen/generate-bytecode-output-root/builtins-generated/bytecodes-builtins-list.h ../../out/Release/v8-qemu-wrapper: 5: exec: /home/aardelean/work/upstream/buildroot/output/host/bin/qemu-arm: not found Return code is 127 [162/2633] CXX obj.host/deps/v8/src/torque/torque_base.torque-parser.o ninja: build stopped: subcommand failed. make[2]: *** [Makefile:127: node] Error 1 make[1]: *** [package/pkg-generic.mk:293: /home/aardelean/work/upstream/buildroot/output/build/nodejs-16.16.0/.stamp_built] Error 2 make: *** [Makefile:84: _all] Error 2 [3] With the BR ARM{64} toolchain I get this here: er_libcdep.lo -MD -MP -MF .deps/sanitizer_symbolizer_libcdep.Tpo -c ../../../../libsanitizer/sanitizer_common/sanitizer_symbolizer_libcdep.cpp -o sanitizer_symbolizer_libcdep.o >/dev/null 2>&1 mv -f .deps/sanitizer_tls_get_addr.Tpo .deps/sanitizer_tls_get_addr.Plo mv -f .deps/sanitizer_symbolizer_libbacktrace.Tpo .deps/sanitizer_symbolizer_libbacktrace.Plo mv -f .deps/sanitizer_stacktrace_libcdep.Tpo .deps/sanitizer_stacktrace_libcdep.Plo mv -f .deps/sanitizer_suppressions.Tpo .deps/sanitizer_suppressions.Plo mv -f .deps/sanitizer_symbolizer_report.Tpo .deps/sanitizer_symbolizer_report.Plo mv -f .deps/sanitizer_stackdepot.Tpo .deps/sanitizer_stackdepot.Plo mv -f .deps/sanitizer_thread_registry.Tpo .deps/sanitizer_thread_registry.Plo mv -f .deps/sanitizer_stoptheworld_linux_libcdep.Tpo .deps/sanitizer_stoptheworld_linux_libcdep.Plo mv -f .deps/sanitizer_symbolizer_posix_libcdep.Tpo .deps/sanitizer_symbolizer_posix_libcdep.Plo mv -f .deps/sanitizer_symbolizer_libcdep.Tpo .deps/sanitizer_symbolizer_libcdep.Plo make[5]: *** [Makefile:531: all-recursive] Error 1 make[4]: *** [Makefile:418: all] Error 2 make[3]: *** [Makefile:12663: all-target-libsanitizer] Error 2 make[2]: *** [Makefile:974: all] Error 2 make[1]: *** [package/pkg-generic.mk:293: /home/aardelean/work/upstream/buildroot/output/build/host-gcc-final-11.3.0/.stamp_built] Error 2 make: *** [Makefile:84: _all] Error 2 > > Thanks > Alexandru > > > > > Best regards, > > > > Thomas > > -- > > Thomas Petazzoni, co-owner and CEO, Bootlin > > Embedded Linux and Kernel engineering and training > > https://bootlin.com
Hello Alexandru, On Sun, 25 Sep 2022 19:15:56 +0300 Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > /home/aardelean/work/upstream/buildroot/output/host/bin/qemu-arm: not > found > Return code is 127 Could you try again with the latest master? Yann just pushed the patch I submitted a few hours ago to fix this. You need to make sure you have at least commit: https://gitlab.com/buildroot.org/buildroot/-/commit/a88ba1548a50d5599e0156d66063dd71545f910b Thanks! Thomas
On Sun, Sep 25, 2022 at 9:41 PM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello Alexandru, > > On Sun, 25 Sep 2022 19:15:56 +0300 > Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > > > /home/aardelean/work/upstream/buildroot/output/host/bin/qemu-arm: not > > found > > Return code is 127 > > Could you try again with the latest master? Yann just pushed the patch > I submitted a few hours ago to fix this. You need to make sure you have > at least commit: > > https://gitlab.com/buildroot.org/buildroot/-/commit/a88ba1548a50d5599e0156d66063dd71545f910b > [ So, as I mentioned earlier, this message was in my Draft folder for a bit ] Tested succesfully with master at this hash https://gitlab.com/buildroot.org/buildroot/-/commit/a8a65d0951e4c93fbba8041ce8e7db1ba8809edc Tested on ARM64 & ARM (RPi4), but with external ARM toolchain (to save some time). I believe that ARM{64} BR toolchains should work just the same. Thanks Alexandru Alexandru > Thanks! > > Thomas > -- > Thomas Petazzoni, co-owner and CEO, Bootlin > Embedded Linux and Kernel engineering and training > https://bootlin.com