Skip to content

zlib change broke x86 builds #33019

Closed
Closed
zlib change broke x86 builds#33019
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.zlibIssues and PRs related to the zlib module and its compression dependencies.

Description

@rvagg
rvagg
opened on Apr 23, 2020

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.

Activity

  1. addaleax commented on Apr 24, 2020

    @addaleax
    addaleax
    on Apr 24, 2020
    Member

    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?

  2. addaleax
    added
    buildIssues and PRs related to Node.js builds or CI infrastructure.
    zlibIssues and PRs related to the zlib module and its compression dependencies.
    on Apr 24, 2020

  3. sam-github commented on Apr 24, 2020

    @sam-github
    sam-github
    on Apr 24, 2020
    Contributor

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

  4. richardlau commented on Apr 24, 2020

    @richardlau
    richardlau
    on Apr 24, 2020
    Member

    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.

  5. richardlau commented on Apr 24, 2020

    @richardlau
    richardlau
    on Apr 24, 2020
    Member

    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.

  6. L3P3 commented on May 3, 2020

    @L3P3
    L3P3
    on May 3, 2020

    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! :)

  7. adnan360 commented on Jul 1, 2020

    @adnan360
    adnan360
    on Jul 1, 2020

    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!

  8. nschonni commented on Oct 4, 2020

    @nschonni
    nschonni
    on Oct 4, 2020
    Member

    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

  9. Neustradamus commented on Oct 15, 2022

    @Neustradamus
    Neustradamus
    on Oct 15, 2022

    To follow this ticket :)

  10. github-actions commented on Jun 27, 2026

    @github-actions
    github-actionsbot
    on Jun 27, 2026 – with GitHub Actions
    Contributor

    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.

  11. github-actions
    added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jun 27, 2026

  12. Neustradamus commented on Jun 28, 2026

    @Neustradamus
    Neustradamus
    on Jun 28, 2026

    What is the situation?

  13. github-actions
    removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jun 28, 2026
  14. jasnell
    closed this as completedon Sep 25, 2026

  15. Neustradamus commented on Sep 28, 2026

    @Neustradamus
    Neustradamus
    on Sep 28, 2026

    @jasnell: Why have you closed this ticket?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildIssues and PRs related to Node.js builds or CI infrastructure.zlibIssues and PRs related to the zlib module and its compression dependencies.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions