Use gcc to compile failed for 32 bit arm target
$ echo 'MACHINE = "qemuarm"' >> conf/local.conf
$ bitbake nodejs
...
2645 | );
| ^
../deps/llhttp/src/llhttp.c:2643:11: error: incompatible type for argument 1 of 'vandq_u16'
2643 | vcgeq_u8(input, vdupq_n_u8(' ')),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| uint8x16_t
...
Use '-flax-vector-conversions' to permit conversions between vectors
with differing element types or numbers of subparts
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
When clang is used as cross compiler, it confuses gyp
system to enable -m64 option for host pieces of build
and the reason is that it assumes clang to be biarch
by default for all architectures but that maybe true for
x86/x86_64 combo but not true for arm/aarch64 systems
This is a backport from node 24
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Plenty of other recipes inherit qemu unconditionally, including
some pretty foundational ones like python3, and they do not need
this fix. I think something else is going on here, and that issue
needs to be properly investigated.
There's a request to provide steps to observe the issue, but the original
patch author so far hasn't been able to reproduce it on demand:
https://lists.openembedded.org/g/openembedded-devel/topic/113861973
This reverts commit b2a950a75b.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The recipe unconditionally inherits the qemu class, because it executes
some target binaries when it is cross-compiled and the bit-width of the
build host and the target host are different.
Since it is unconditional, it also means that it is inherited for native
and nativesdk builds also. The qemu class uses some qemu options that are
always derived from the target machine's configuration, even when the
recipe is built for class-native. This means that some of the variables
used by the recipe changes (e.g. QEMU_OPTIONS), and the shared state cache
is invalidated when the target machine changes, even when nodejs-native is
being built - and it triggers a full rebuild of nodejs-native unnecessarily.
To avoid this, inherit the qemu class conditionally, only in case it is
used (when the target and build arch's bit-widths are different).
Also, inherit qemu-native based on the same condition, and move around the
qemu-dependent code a bit, so it will be only executed when the qemu class
is inherited.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Please see
https://git.yoctoproject.org/poky/commit/?id=4dd321f8b83afecd962393101b2a6861275b5265
for what changes are needed, and sed commands that can be used to make them en masse.
I've verified that bitbake -c patch world works with these, but did not run a world
build; the majority of recipes shouldn't need further fixups, but if there are
some that still fall out, they can be fixed in followups.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This reverts commit 24ff52ba3b.
The original patch was my bad. The patches for oe-core were re-worked,
but I forgot the recall this patch.
In fact, inheriting qemu is needed because it sets a clear barriar
for people to use qemu user mode. And the QEMU_OPTIONS settings
are also in qemu.bbclass.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Avoid inheriting qemu.bbclass and use oe.qemu.xxx instead.
Also, the 'qemu-native' dep is replaced by 'qemuwrapper-cross' for
PACKAGE_WRITE_DEPS. qemuwrapper-cross is the one that is actually
used by postints and it has 'qemu-native' in DEPENDS.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This moves us from the previous Long Term Support version codenamed 'Iron' to the newly
released Long Term Support version 22.11.0 Codename 'Jod'
Changelog: https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V22.md#22.11.0
License-Update:
Add amaro dependency under MIT License.
Add swc dependency under Aapche License Version 2.0.
Add simdjson dependency under Apache License Version 2.0.
Add on-exit-leak-free under MIT License.
Remove ESLint.
Remove base64 dependency.
Removed patchs:
182d9c05e78.patch - This was a backport to 20.x it is now integrated in 22.x
Added patches:
Two small patches here to use Bourne Shell instad of BASH.
0001-custom-env.patch
0001-positional-args.patch
This patch from https://github.com/nodejs/node/commit/686da19abb that addressed CVE-2024-22017
0001-deps-disable-io_uring-support-in-libuv.patch
Other patches were refreshed.
Signed-off-by: Jason Schonberg <schonm@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Drop two patches which haven't been referenced by the nodejs recipe since the
20.11.0 version checkin.
0001-build-fix-build-with-Python-3.12.patch
0001-gyp-resolve-python-3.12-issues.patch
Signed-off-by: Jason Schonberg <schonm@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
As noted in the libc++ 19 release notes [1], std::char_traits<> is now
only provided for char, char8_t, char16_t, char32_t and wchar_t, and any
instantiation for other types will fail.
This causes nodejs-20 to fail to compile with clang 19 and libc++ 19,
resulting in errors similar to:
/usr/include/c++/v1/string:820:42: error: implicit instantiation of undefined template 'std::char_traits<unsigned short>'
820 | static_assert(is_same<_CharT, typename traits_type::char_type>::value,
| ^
../deps/v8/src/inspector/string-16.h:114:28: note: in instantiation of template class 'std::basic_string<unsigned short>' requested here
114 | std::basic_string<UChar> m_impl;
| ^
/usr/include/c++/v1/__fwd/string.h:23:29: note: template is declared here
23 | struct _LIBCPP_TEMPLATE_VIS char_traits;
| ^
Upstream v8 has fixed this in commit 182d9c05e78 [2], so add it as a
backported patch, until the next version of node is released.
[1] https://libcxx.llvm.org/ReleaseNotes/19.html#deprecations-and-removals
[2] https://chromium.googlesource.com/v8/v8.git/+/182d9c05e78
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Due to the scope of supported BSPs by qemu-user is limited, such
as a segment fault on armv9 after qemu apply commit [target/arm:
Convert LDAPR/STLR (imm) to decodetree][1]
```
|tmp-glibc/work/neoversen2-crypto-wrs-linux/nodejs/20.5.1/node-v20.5.1/out/
Release/v8-qemu-wrapper.sh: line 7: 3179613 Segmentation fault (core dumped)
PSEUDO_UNLOAD=1 qemu-aarch64 -r 5.15 -L tmp-glibc/work/neoversen2-crypto-wrs-linux/
nodejs/20.5.1/recipe-sysroot -E LD_LIBRARY_PATH=tmp-glibc/work/neoversen2-crypto-wrs-linux/
nodejs/20.5.1/recipe-sysroot/usr/lib64:tmp-glibc/work/neoversen2-crypto-wrs-linux/
nodejs/20.5.1/recipe-sysroot/usr/lib64 "$@"
```
Upstream nodejs have cross compile support, but it needs host and target
have same bit width (e.g. a x86_64 host targeting arrch64 to produce a
64-bit binary). So:
1. If host and target have different bit width, build with QEMU user as usual;
2. If host and target have same bit width, enable notejs cross compile support:
- The build tools of nodejs is GYP[2], set CC_host, CFLAGS_host,
CXX_host, CXXFLAGS_host, LDFLAGS_host, AR_host for host build
which is separated with target build [3]
- Satisfy layer compatibility, set GYP variables in prefuncs of do_configure,
do_compile and do_install other than in recipe parsing
- Add missing native packages to fix library missing on host build
- Rework libatomic.patch, explicitly link to libatomic for clang
conditionally
[1] https://github.com/qemu/qemu/commit/2521b6073b7b4b505533a941d4f9600f7585dc78
[2] https://github.com/nodejs/node-gyp
[3] https://github.com/nodejs/node-gyp/blob/main/gyp/docs/UserDocumentation.md#cross-compiling
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* oe-npm-cache is now in UNPACKDIR not WORKDIR
* fixes:
http://errors.yoctoproject.org/Errors/Details/771012/
/OE/build/oe-core/tmp-glibc/work/x86_64-linux/nodejs-oe-cache-native/20.13/temp/run.do_configure.1268826: line 142: /OE/build/oe-core/tmp-glibc/work/x86_64-linux/nodejs-oe-cache-native/20.13/oe-npm-cache: No such file or directory
* set S and UNPACKDIR to avoid this as well:
WARNING: nodejs-oe-cache-native-20.13-r0 do_unpack: nodejs-oe-cache-native: the directory ${WORKDIR}/${BP} (/OE/build/oe-core/tmp-glibc/work/x86_64-linux/nodejs-oe-cache-native/20.13/nodejs-oe-cache-20.13) pointed to by the S variable doesn't exist - please set S within the recipe to point to where the source has been unpacked to
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Apparently, npm has changed its request accept header, so that cache
lookup misses. This causes an ENOTCACHED error when doing the offline
install in do_compile() from npm.bbclass.
Fix it by updating the fake cache entry to match the newest behaviour
from npm.
Note that npm doesn't agree with itself, as it still uses the previous
header value when doing `npm cache add <pkg>`, but the new value when
doing `npm install <pkg>`.
Bug submitted upstream:
https://github.com/npm/cli/issues/7465
Signed-off-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The original idea was always disable io_uring to avoid follwing failure
even when UV_USE_IO_URING is set to true, refer [1][2]:
0608: try:
*** 0609: update_hash(" %10s" % pwd.getpwuid(s.st_uid).pw_name)
0610: update_hash(" %10s" % grp.getgrgid(s.st_gid).gr_name)
0611: except KeyError as e:
0612: msg = ("KeyError: %s\nPath %s is owned by uid %d, gid %d, which doesn't match "
0613: "any user/group on target. This may be due to host contamination." %
Exception: Exception: KeyError: 'getpwuid(): uid not found: 20561'
But since 20.11.1, for fix CVE-2024-22017, io_uring is disabled by
default, refer [3]. So maybe patch
0001-deps-disable-io_uring-support-in-libuv.patch is not needed.
For case UV_USE_IO_URING is set to true, user can fix above failure
by "chown root:root -R ${D}" in do_install.
[1] https://lists.openembedded.org/g/openembedded-devel/message/105583
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15244
[3] https://github.com/nodejs/node/commit/686da19abbb83b7e01d48be19f832ab081b87084
[4] https://nvd.nist.gov/vuln/detail/CVE-2024-22017
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Drop patches for revert io_uring support in libuv:
0001-Revert-io_uring-changes-from-libuv-1.46.0.patch
0002-Revert-io_uring-changes-from-libuv-1.45.0.patch
Change to just always disable io_uring in libuv, in this way, we don't have to
pick out io_uring related changes and revert them when internal libuv
upgraded.
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* Pseudo fails to intercept some of the syscalls used by the
new version as documented in:
https://github.com/shr-project/com.webos.app.minimal/tree/recipes
Now we have 3 options:
1) every use of nodejs-native where io_uring might be used (like in webpack)
needs to export UV_USE_IO_URING=0 before using node, but be aware that
the PR says it's only temporary and this variable might be removed in future.
Unfortunately many people are lucky enough not to know what pseudo even is,
so they might not realize that host-user-contamination QA issues or
"KeyError: 'getpwuid(): uid not found" might be related to this (and they
probably won't find this e-mail as well:
https://lists.openembedded.org/g/openembedded-devel/message/105583
2) revert the io_uring changes from bundled libuv, to make sure it stays disabled.
The changes are massive and it will be PIA to update them for every nodejs release
I've already separated them for nodejs-20.3.0 where I've initialy tested this
on top of libuv-1.45.0 and for 20.4.0 this need another patch for changes
from libuv-1.46.0.
Patch for keeping UV_USE_IO_URING support after it's removed from upstream libuv
will be much smaller, but PIA to use UV_USE_IO_URING whenever using nodejs-native
during build.
3) fix pseudo to correctly work with io_uring calls, definitely best long-term solution
as more and more tools will now switch to io_uring, but without active maintainer
of pseudo it might be _very_ difficult to implement this and there aren't many
people willing to touch this beast.
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* mksnapshot is built as host binary, but then gets executed under
qemu-arm, because for 32bit target we need to run 32bit mksnapshot
even when building on x86-64 host
* unfortunately since upgrade to qemu-8 in:
https://git.openembedded.org/openembedded-core/commit/?id=fe8125565af07b73f9b29db2188ecb6e884bcc70
the mksnapshot fails to execute with:
LD_LIBRARY_PATH=/OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/node-v18.16.0/out/Release/lib.host:/OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/node-v18.16.0/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../tools/v8_gypfiles; mkdir -p /OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/node-v18.16.0/out/Release/obj.target/v8_snapshot/geni; "/OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/node-v18.16.0/out/Release/v8-qemu-wrapper.sh" "/OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/node-v18.16.0/out/Release/mksnapshot" --turbo_instruction_scheduling "--target_os=linux" "--target_arch=arm" --startup_src "/OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/node-v18.16.0/out/Release/obj.target/v8_snapshot/geni/snapshot.cc" --embedded_variant Default --embedded_src "/OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/node-v18.16.0/out/Release/obj.target/v8_snapshot/geni/embedded.S" --no-native-code-counters
#
# Fatal process OOM in Failed to reserve virtual memory for CodeRange
#
/OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/node-v18.16.0/out/Release/v8-qemu-wrapper.sh: line 7: 669880 Trace/breakpoint trap (core dumped) PSEUDO_UNLOAD=1 qemu-arm -r 5.15 -L /OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/recipe-sysroot -E LD_LIBRARY_PATH=/OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/recipe-sysroot/usr/lib:/OE/build/oe-core/tmp-glibc/work/cortexa8t2hf-neon-oe-linux-gnueabi/nodejs/18.16.0-r0/recipe-sysroot/lib "$@"
It was failing only in some of my builds first, in the end
I was able to narrow the difference between the build where
it fails and where it doesn't fail to
require conf/distro/include/security_flags.inc
then
GCCPIE = "--enable-default-pie"
and lastly this PIE enabled just for nodejs to work around
this issue without downgrading qemu-native.
* using -strace with qemu doesn't help much, just confirms that
the OOM error message is really caused by failed mmap2:
--- SIGPROF {si_signo=SIGPROF, si_code=SI_TKILL, si_pid=2908258, si_uid=1026} ---
clock_gettime64(CLOCK_MONOTONIC,0x407ef640) = 0 ({tv_sec=20187,tv_nsec=678404286})
rt_sigreturn(0x407efb70) = -1 errno=513 (Successful exit from sigreturn)
write(3,0x141e538,28) = 28
write(3,0x141e538,28) = 28
write(3,0x141e538,32) = 32
mmap2(0x0097a000,33554432,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,-1,0) = -1 errno=12 (Cannot allocate memory)
mmap2(0x0097a000,33554432,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,-1,0) = -1 errno=12 (Cannot allocate memory)
* diffoscope on this 1.7G binary didn't really help as it got killed by OOMK after a while
Out of memory: Killed process 1136999 (diffoscope) total-vm:404300108kB, anon-rss:122594688kB, file-rss:512kB, shmem-rss:0kB, UID:1026 pgtables:764240kB oom_score_adj:0
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Jason Schonberg
Gyorgy Sarvari
Hongxu Jia
Khem Raj
Alexander Kanavin
Alexander Kanavin
Chen Qi
Jeroen Hofstee
Martin Jansa
Martin Hundebøll
Archana Polampalli
Changqing Li
virendra thakur