search

nodejs / node

Node.js JavaScript runtime ✨🐢🚀✨
https://nodejs.org
Other
107.13k stars 29.36k forks source link

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

Open ash-hannigan opened 3 years ago

ash-hannigan commented 3 years ago

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 commented 3 years ago

cc @nodejs/build

sxa commented 3 years ago

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 commented 3 years ago

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 https://github.com/nodejs/node/pull/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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 2 years ago

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

ash-hannigan commented 2 years ago

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!