zlib change broke x86 builds

[rvagg]

I know we don't officially support x86 anymore but we do publish unofficial-builds x86 and the Snap package has x86 support too. But I've just noticed they haven't been building, I suppose since zlib was switched out:

  cc -o /build/node/parts/node/build/out/Release/obj.target/zlib/deps/zlib/contrib/optimizations/inflate.o ../deps/zlib/contrib/optimizations/inflate.c '-DV8_DEPRECATION_WARNINGS' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D__STDC_FORMAT_MACROS' '-DOPENSSL_NO_PINSHARED' '-DOPENSSL_THREADS' '-DHAVE_HIDDEN' '-DADLER32_SIMD_SSSE3' '-DINFLATE_CHUNK_SIMD_SSE2' '-DCRC32_SIMD_SSE42_PCLMUL' -I../deps/zlib  -pthread -Wall -Wextra -Wno-unused-parameter -m32 -O3 -fno-omit-frame-pointer  -MMD -MF /build/node/parts/node/build/out/Release/.deps//build/node/parts/node/build/out/Release/obj.target/zlib/deps/zlib/contrib/optimizations/inflate.o.d.raw   -c
In file included from ../deps/zlib/contrib/optimizations/inffast_chunk.c:10:0:
../deps/zlib/contrib/optimizations/chunkcopy.h: In function ‘loadchunk’:
../deps/zlib/contrib/optimizations/chunkcopy.h:52:5: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
     const unsigned char FAR* s) {
     ^
In file included from ../deps/zlib/contrib/optimizations/inflate.c:87:0:
../deps/zlib/contrib/optimizations/chunkcopy.h: In function ‘loadchunk’:
../deps/zlib/contrib/optimizations/chunkcopy.h:52:5: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
     const unsigned char FAR* s) {
     ^
In file included from ../deps/zlib/contrib/optimizations/chunkcopy.h:32:0,
                 from ../deps/zlib/contrib/optimizations/inffast_chunk.c:10:
../deps/zlib/contrib/optimizations/chunkcopy.h: In function ‘v_load64_dup’:
/usr/lib/gcc/i686-linux-gnu/5/include/emmintrin.h:625:1: error: inlining failed in call to always_inline ‘_mm_set1_epi64x’: target specific option mismatch
 _mm_set1_epi64x (long long __A)
 ^
In file included from ../deps/zlib/contrib/optimizations/inffast_chunk.c:10:0:
../deps/zlib/contrib/optimizations/chunkcopy.h:215:10: error: called from here
   return _mm_set1_epi64x(i64);
          ^
make[1]: *** [/build/node/parts/node/build/out/Release/obj.target/zlib/deps/zlib/contrib/optimizations/inffast_chunk.o] Error 1
make[1]: *** Waiting for unfinished jobs....
deps/zlib/zlib.target.mk:109: recipe for target '/build/node/parts/node/build/out/Release/obj.target/zlib/deps/zlib/contrib/optimizations/inffast_chunk.o' failed
In file included from ../deps/zlib/contrib/optimizations/chunkcopy.h:32:0,
                 from ../deps/zlib/contrib/optimizations/inflate.c:87:
../deps/zlib/contrib/optimizations/chunkcopy.h: In function ‘v_load64_dup’:
/usr/lib/gcc/i686-linux-gnu/5/include/emmintrin.h:625:1: error: inlining failed in call to always_inline ‘_mm_set1_epi64x’: target specific option mismatch
 _mm_set1_epi64x (long long __A)
 ^
In file included from ../deps/zlib/contrib/optimizations/inflate.c:87:0:
../deps/zlib/contrib/optimizations/chunkcopy.h:215:10: error: called from here
   return _mm_set1_epi64x(i64);
          ^
make[1]: *** [/build/node/parts/node/build/out/Release/obj.target/zlib/deps/zlib/contrib/optimizations/inflate.o] Error 1
deps/zlib/zlib.target.mk:109: recipe for target '/build/node/parts/node/build/out/Release/obj.target/zlib/deps/zlib/contrib/optimizations/inflate.o' failed
rm 73eb81ec782978e9e5a9028cb1d0640d4778b4fe.intermediate
make: *** [node] Error 2
Makefile:101: recipe for target 'node' failed

I suspect there might be a not-too-difficult fix to restore support here, maybe bypassing an optimisation that was added? We still have x86 users so I'm sure a fix will be appreciated if we can come up with one.

[addaleax]

This might have been caused by #32627 (which is just a workaround for now, until we have a proper gyp-only fix in place)… I could probably fix this, but I’m not sure how easy it is to set up a 32-bit Linux system these days? Do we have any in CI that I could test this on?

[sam-github]

@addaleax There are some digitial ocean ubuntu x86 machines, maybe test-digitalocean-ubuntu1604-x86-1 ? You have ssh access (or should, I just checked, I do). I scanned ci.nodejs.org/computers to find them, looked like at least one softlayer machine, too.

[richardlau]

This might have been caused by #32627 (which is just a workaround for now, until we have a proper gyp-only fix in place)… I could probably fix this, but I’m not sure how easy it is to set up a 32-bit Linux system these days? Do we have any in CI that I could test this on?

Re. a "proper gyp-only fix", I'm about to PR a rework of the zlib gyp files based on the gn files.

[richardlau]

This might have been caused by #32627 (which is just a workaround for now, until we have a proper gyp-only fix in place)… I could probably fix this, but I’m not sure how easy it is to set up a 32-bit Linux system these days? Do we have any in CI that I could test this on?

Re. a "proper gyp-only fix", I'm about to PR a rework of the zlib gyp files based on the gn files.

And here it is: #33044
I don't know for certain if it fixes this issue as the Linux server I've been working on doesn't have g++ multilib so compiling V8 fails.

[L3P3]

There are millions of embedded industrial boxes out there running linux on x86; this issue just appeared to me when updating node on one of them. Most of these would stay productive for many years to come (due to stability, almost no energy consumption, low service costs etc.) unless issues like these made us a stroke through the bill. Actually loosing the option to develop current software for them via node with npm modules would be a desaster for many engineers... Thanks a lot for your effort! :)

[adnan360]

And here it is: #33044
I don't know for certain if it fixes this issue as the Linux server I've been working on doesn't have g++ multilib so compiling V8 fails.

@richardlau
I built your branch on a 32-bit Sparky Linux (Debian) with testing repos. Before, I tried 14.x (even tried master from today) and it was failing with above message. So I did:

$ git clone -b gypfiles https://github.com/richardlau/node-1.git
$ cd node-1
$ ./configure
$ make -j 3

It built just fine ending with:

  g++ -o /home/username/compile/node-1/out/Release/node -pthread -rdynamic -m32 -Wl,--whole-archive /home/username/compile/node-1/out/Release/obj.target/libnode.a /home/username/compile/node-1/out/Release/obj.target/tools/v8_gypfiles/libv8_base_without_compiler.a -Wl,--no-whole-archive -Wl,--whole-archive /home/username/compile/node-1/out/Release/obj.target/deps/zlib/libzlib.a -Wl,--no-whole-archive -Wl,--whole-archive /home/username/compile/node-1/out/Release/obj.target/deps/uv/libuv.a -Wl,--no-whole-archive -Wl,-z,noexecstack -Wl,--whole-archive /home/username/compile/node-1/out/Release/obj.target/tools/v8_gypfiles/libv8_snapshot.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,-z,now -Wl,--whole-archive,/home/username/compile/node-1/out/Release/obj.target/deps/openssl/libopenssl.a -Wl,--no-whole-archive -pthread  -Wl,--start-group /home/username/compile/node-1/out/Release/obj.target/node/src/node_main.o /home/username/compile/node-1/out/Release/obj.target/node/gen/node_code_cache.o /home/username/compile/node-1/out/Release/obj.target/node/gen/node_snapshot.o /home/username/compile/node-1/out/Release/obj.target/deps/
histogram/libhistogram.a /home/username/compile/node-1/out/Release/obj.target/deps/uvwasi/libuvwasi.a /home/username/compile/node-1/out/Release/obj.target/libnode.a /home/username/compile/node-1/out/Release/obj.target/tools/v8_gypfiles/libv8_snapshot.a /home/username/compile/node-1/out/Release/obj.target/tools/v8_gypfiles/libv8_libplatform.a /home/username/compile/node-1/out/Release/obj.target/tools/icu/libicui18n.a /home/username/compile/node-1/out/Release/obj.target/deps/zlib/libzlib.a /home/username/compile/node-1/out/Release/obj.target/deps/llhttp/libllhttp.a /home/username/compile/node-1/out/Release/obj.target/deps/cares/libcares.a /home/username/compile/node-1/out/Release/obj.target/deps/uv/libuv.a /home/username/compile/node-1/out/Release/obj.target/deps/nghttp2/libnghttp2.a /home/username/compile/node-1/out/Release/obj.target/deps/brotli/libbrotli.a /home/username/compile/node-1/out/Release/obj.target/deps/openssl/libopenssl.a /home/username/compile/node-1/out/Release/obj.target/tools/icu/libicuucx.a /home/username/compile/node-1/out/Release/obj.target/tools/icu/libicudata.a /home/username/compile/node-1/out/Release/obj.target/tools/v8_gypfiles/libv8_base_without_compiler.a /home/username/compile/node-1/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a /home/username/compile/node-1/out/Release/obj.target/tools/v8_gypfiles/libv8_libsampler.a /home/username/compile/node-1/out/Release/obj.target/tools/v8_gypfiles/libv8_zlib.a /home/username/compile/node-1/out/Release/obj.target/tools/v8_gypfiles/libv8_compiler.a /home/username/compile/node-1/out/Release/obj.target/tools/v8_gypfiles/libv8_initializers.a /home/username/compile/node-1/out/Release/obj.target/deps/zlib/libzlib_crc32_simd.a /home/username/compile/node-1/out/Release/obj.target/deps/zlib/libzlib_x86_simd.a -lm -ldl -Wl,--end-group
rm 20cc07e8e6346b9ab40a45f6b20bab36a056c7d3.intermediate b46af718622560f4ef215f0fe6fcd2726b911c08.intermediate c9b71edef761415a2c8cd37e5df65678a7d41484.intermediate cacdc0564a2519d2c446953ed2a13ae3af4ff085.intermediate
if [ ! -r node -o ! -L node ]; then ln -fs out/Release/node node; fi

Afterwards,

$ nvm alias default system # I had nvm installed, so had to run it
$ node --version
v13.8.0
$ sudo make install
$ node --version
v15.0.0-pre

Thanks a lot. Now I have Node 15 working on my 32-bit machine!
Looking forward to see unofficial builds for 32-bit again!

[nschonni]

Just cross posting this from the docker build, as it look like the latest v12 and v14 are failing for x86 https://doi-janky.infosiftr.net/job/multiarch/view/images/view/node/job/i386/job/node/322/console
If the intention is that the support might be added back as at the experimental level we can leave it, otherwise we can just remove it from the cross-compile CI