Repository navigation
zlib.gyp is not configured for armv7 builds node V14.17.2 #39276
Description
Activity
- changed the title
[-]zlib.gyp in snot configured for armv7 builds node V14.17.2[/-][+]zlib.gyp is not configured for armv7 builds node V14.17.2[/+]on Jul 5, 2021 cc @nodejs/build
Hmmm that looks a bit odd - I don't believe we've seen those failures in the CI so far, and it's a platform we cross-compile for ourselves.
I've just downloaded and tested https://nodejs.org/dist/v14.17.3/node-v14.17.3-linux-armv7l.tar.xz on one of my armv7l-only systems and it appears to run ok, which suggests that it may be some extra options that you need to make it build correctly.
Our CI is cross compiling for armv7l -- I don't believe we have armv7-a. Cross compilation for armv6l also still appears to be working over in https://github.com/nodejs/unofficial-builds.
You could try #33044 which is a closer translation of the .gn build files from upstream Chromium's zlib fork. It did at least reportedly fix issues with optimizations not being available on x86. It hasn't been merged because it seems to introduce a performance regression in the zlib benchmarks that I'm at a loss to explain.
Where did you get your cross-compiler from and which options did you use to set up the node build system. When targetting armv7 it really shouldn't be trying to go through any of the ARMv8 compilation paths.
@richardlau Looking at https://ci.nodejs.org/job/node-cross-compile/nodes=cross-compiler-ubuntu1804-armv7-gcc-8/34648/consoleFull we are explicitly setting
-march=armv7-ain theCCdefinition:15:12:58 python3 ./configure --verbose --dest-cpu=arm 15:13:02 Node.js configure: Found Python 3.6.9... 15:13:02 Detected C++ compiler (CXX=ccache /opt/raspberrypi/rpi-newer-crosstools/x64-gcc-8.3.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-g++ -march=armv7-a) version: 8.3.0 15:13:02 Detected C compiler (CC=ccache /opt/raspberrypi/rpi-newer-crosstools/x64-gcc-8.3.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-gcc -march=armv7-a) version: 8.3.0@Sma5hley it might be worth comparing that log file to see if there's anything different in terms of what you're passing in to the buid process
Reacted by Richard Lau@sxa The cross-compiler I'm using is a little dated because it needs to support the embedded platform (gcc 6.5.0, glibc 2.29).
The exports in the log file look very similar to what I'm using in my makefile. I might try building with the --verbose flag and see if that reveals anything not being assigned / detected correctly. I am also assigning -march=armv7-a to the gcc g++ env variables. One difference is I'm using ARCH=arm instead of ARCH=armv7l.. Could that be causing any problems?
The only check I can see in zlib.gyp for whether or not to apply armv8 optimisations is checking for arm_fpu=neon (deps/zlib/zlib.gyp:103).
When I set -march=armv7-a it appears to get overwritten by the zlib flags, which probably confuses things more.
Anyway, I'll clean and build again with --verbose enabled and report back with what I find. For now I just commented out the optimisations and everything built without error.. I've got other problems with library linking, but I suspect that's a different story.
@Sma5hley I have the same issue. Any solution? Can you please share how to turn off the optimization? What to comment out?
Hi @tomerpetel, I never ended up working it out unfortunately. I got it to build, but it segfaulted when I tried to run it on the target unit. My flags as of my last attempt more than a year ago where:
ARCH:= arm TARGET_ARCH:= -march=armv7-a TARGET_TUNE:= -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp CONFIG_OPTIONS:= --prefix=/ --cross-compiling --dest-os=linux --dest-cpu=$(ARCH) --with-arm-float-abi=softfp --with-arm-fpu=neon --v8-lite-mode --without-intlSorry I can't be of any more help!
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Version
14.17.2
Platform
ARMV7l
Subsystem
No response
What steps will reproduce the bug?
Cross-compiling from linux for arm-linux with ARMv7-a.
I've been running into issues when compiling zlib in particular:
In file included from ../deps/zlib/deflate.c:54:0: ../deps/zlib/contrib/optimizations/insert_string.h:39:0: warning: "TARGET_CPU_WITH_CRC" redefined #define TARGET_CPU_WITH_CRC __attribute__((target("armv8-a,crc")))I might be wrong here but I believe that zlib.gyp is not respecting the arm_version and attempting to optimise using flags that aren't supported in armv7-a.
zlib.gyp has the following condition statement for arm-fpu=="neon":
['arm_fpu=="neon"', { 'defines': [ 'ADLER32_SIMD_NEON', 'INFLATE_CHUNK_SIMD_NEON', ], 'sources': [ 'contrib/optimizations/slide_hash_neon.h', ], 'conditions': [ ['OS!="ios"', { 'defines': [ 'CRC32_ARMV8_CRC32' ], 'sources': [ 'arm_features.c', 'arm_features.h', 'crc32_simd.c', 'crc32_simd.h', ], 'conditions': [ ['OS=="android"', { 'defines': [ 'ARMV8_OS_ANDROID' ], }], ['OS=="linux"', { 'defines': [ 'ARMV8_OS_LINUX' ], }], ['OS=="win"', { 'defines': [ 'ARMV8_OS_WINDOWS' ], }], ['OS!="android" and OS!="win" and llvm_version=="0.0"', { 'cflags': [ '-march=armv8-a+crc', ], }], ], }], ['target_arch=="arm64"', { 'defines': [ 'INFLATE_CHUNK_READ_64LE' ], }], ], }],armv7-a doesn't support CRC32_ARMV8_CRC32, ARMV8_OS_LINUX, or setting -march=armv8-a+crc
This causes the build of zlib to fail.
I believe there needs to be a check in here somewhere for arm_version, before trying to optimise for the incorrect architecture.
Unless of course I'm missing an ENV variable declaration somewhere that would avoid this?
Thanks for all you work!
How often does it reproduce? Is there a required condition?
Cross compiling for ARMV7-A target.
What is the expected behavior?
No response
What do you see instead?
No response
Additional information
No response