Repository navigation
zlib change broke x86 builds #33019
Description
Activity
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?
@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.
Reacted by Anna HenningsenThis 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.
Reacted by LenThis 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.Reacted by adnan360There 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! :)
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 3It 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; fiAfterwards,
$ 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-preThanks a lot. Now I have Node 15 working on my 32-bit machine!
Looking forward to see unofficial builds for 32-bit again!Reacted by masx200Just 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 CITo follow this ticket :)
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.What is the situation?
@jasnell: Why have you closed this ticket?
Reacted by Len
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:
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.