zlib.gyp is not configured for armv7 builds node V14.17.2

[ash-hannigan]

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

[Ayase-252]

cc @nodejs/build

[sxa]

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.

[richardlau]

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.

[sxa]

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.

[sxa]

@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-a in the CC definition:

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

[ash-hannigan]

@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.

[tomerpetel]

@Sma5hley I have the same issue. Any solution? Can you please share how to turn off the optimization? What to comment out?

[ash-hannigan]

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-intl

Sorry I can't be of any more help!