mbox series

[00/13] package/nodejs: rework cross-building

Message ID 20220809075704.86472-1-ardeleanalex@gmail.com
Headers show
Series package/nodejs: rework cross-building | expand

Message

Alexandru Ardelean Aug. 9, 2022, 7:56 a.m. UTC
A bit of introduction here.

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.

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.

I eventually got nodejs to build & run on an RPi4 32 & 64 bit.

I'm not sure if this patchset is fully correct.

But some things can be useful from it:
* the host-libuv and host-nghttp2 packages (for other potential users)
* the 'fix ARM build with VFP3 instruction' patch (maybe)
* the 'build host-nodejs only if we're installing modules with NPM' patch
  looks to me that even without this rework, if we don't install any node
  modules on the target, we don't really need the host-nodejs build

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

 package/libuv/libuv.mk                        |  3 +
 package/nghttp2/nghttp2.mk                    |  1 +
 .../0001-add-qemu-wrapper-support.patch       | 88 -------------------
 ...lude-obj-name-in-shared-intermediate.patch | 24 +++++
 ...-x64-cross-compile-for-32-bit-target.patch | 71 +++++++++++++++
 package/nodejs/Config.in                      |  7 +-
 package/nodejs/Config.in.host                 |  5 +-
 package/nodejs/nodejs.mk                      | 67 +++++---------
 package/nodejs/v8-qemu-wrapper.in             |  9 --
 9 files changed, 129 insertions(+), 146 deletions(-)
 delete mode 100644 package/nodejs/0001-add-qemu-wrapper-support.patch
 create mode 100644 package/nodejs/0002-include-obj-name-in-shared-intermediate.patch
 create mode 100644 package/nodejs/0003-fix-host-x64-cross-compile-for-32-bit-target.patch
 delete mode 100644 package/nodejs/v8-qemu-wrapper.in

Comments

Thomas Petazzoni Aug. 9, 2022, 11:42 a.m. UTC | #1
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
Alexandru Ardelean Aug. 9, 2022, 12:48 p.m. UTC | #2
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
Thomas Petazzoni Aug. 10, 2022, 9:23 p.m. UTC | #3
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
Alexandru Ardelean Aug. 11, 2022, 7:48 a.m. UTC | #4
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
Thomas Petazzoni Sept. 25, 2022, 8:27 a.m. UTC | #5
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
Alexandru Ardelean Sept. 25, 2022, 3:17 p.m. UTC | #6
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
Alexandru Ardelean Sept. 25, 2022, 4:15 p.m. UTC | #7
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
Thomas Petazzoni Sept. 25, 2022, 6:41 p.m. UTC | #8
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
Alexandru Ardelean Sept. 26, 2022, 1:11 p.m. UTC | #9
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