unable to build master, linking fails

[devsnek]

I'm using clang 9.0.0 on linux 5.4. gcc libc++ is at 9.2.0

/usr/bin/ld: node/out/Release/mkcodecache: section .tbss._ZN2v88internal12trap_handler21g_thread_in_wasm_codeE lma 0x3ad7d10 adjusted to 0x3ad7d18
/usr/bin/ld: node/out/Release/mkcodecache: section .tbss._ZN2v88internal4wasm12_GLOBAL__N_123current_code_refs_scopeE lma 0x3ad7d10 adjusted to 0x3ad7d1c
/usr/bin/ld: node/out/Release/node_mksnapshot: section .tbss._ZN2v88internal12trap_handler21g_thread_in_wasm_codeE lma 0x3adc138 adjusted to 0x3adc140
/usr/bin/ld: node/out/Release/node_mksnapshot: section .tbss._ZN2v88internal4wasm12_GLOBAL__N_123current_code_refs_scopeE lma 0x3adc138 adjusted to 0x3adc144
/usr/bin/ld: /usr/lib/libc_nonshared.a(elf-init.oS): in function `__libc_csu_init':
(.text+0x9): undefined reference to `__init_array_start'
/usr/bin/ld: (.text+0x20): undefined reference to `__init_array_end'
/usr/bin/ld: node/out/Release/mkcodecache: hidden symbol `__init_array_end' isn't defined
/usr/bin/ld: final link failed: bad value
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [mkcodecache.target.mk:211: node/out/Release/mkcodecache] Error 1
make[1]: *** Waiting for unfinished jobs....
/usr/bin/ld: /usr/lib/libc_nonshared.a(elf-init.oS): in function `__libc_csu_init':
(.text+0x9): undefined reference to `__init_array_start'
/usr/bin/ld: (.text+0x20): undefined reference to `__init_array_end'
/usr/bin/ld: node/out/Release/node_mksnapshot: hidden symbol `__init_array_end' isn't defined
/usr/bin/ld: final link failed: bad value
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [node_mksnapshot.target.mk:211: node/out/Release/node_mksnapshot] Error 1
/usr/bin/ld: node/out/Release/cctest: section .tbss._ZN2v88internal12trap_handler21g_thread_in_wasm_codeE lma 0x3d1a090 adjusted to 0x3d1a098
/usr/bin/ld: node/out/Release/cctest: section .tbss._ZN2v88internal4wasm12_GLOBAL__N_123current_code_refs_scopeE lma 0x3d1a090 adjusted to 0x3d1a09c
/usr/bin/ld: /usr/lib/libc_nonshared.a(elf-init.oS): in function `__libc_csu_init':
(.text+0x9): undefined reference to `__init_array_start'
/usr/bin/ld: (.text+0x20): undefined reference to `__init_array_end'
/usr/bin/ld: /node/out/Release/cctest: hidden symbol `__init_array_end' isn't defined
/usr/bin/ld: final link failed: bad value
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [cctest.target.mk:236: node/out/Release/cctest] Error 1
rm 2c2d90d92af32fa2bd6374898760f9e3aec01744.intermediate 92dd4eeebf8d109ba8aadeb5d36dbd389740ec6b.intermediate f12c036df8642cb80f280f6ba7af1a2f28745260.intermediate 81e1bdc2cb7a88361a91e3d45a5b35e6715c2ab6.intermediate
make: *** [Makefile:101: node] Error 2

[bnoordhuis]

Can you include the part of the output where ld or g++ / clang++ is invoked to do the link?

__init_array_start and __init_array_end is the list of static constructors, by the way.

[devsnek]

@bnoordhuis

ccache clang++ -o /home/snek/Desktop/misc/nodejs/node/out/Release/node_mksnapshot -pthread -rdynamic -m64 -Wl,--whole-archive /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/zlib/libzlib.a -Wl,--no-whole-archive -Wl,--whole-archive /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/uv/libuv.a -Wl,--no-whole-archive -Wl,-z,noexecstack -Wl,--whole-archive /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/v8_gypfiles/libv8_snapshot.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,-z,now -Wl,-T /home/snek/Desktop/misc/nodejs/node/src/large_pages/ld.implicit.script.lld -Wl,--whole-archive,/home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/openssl/libopenssl.a -Wl,--no-whole-archive -pthread -Wl,--start-group /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/node_mksnapshot/src/node_snapshot_stub.o /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/node_mksnapshot/src/node_code_cache_stub.o /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/node_mksnapshot/tools/snapshot/node_mksnapshot.o /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/node_mksnapshot/tools/snapshot/snapshot_builder.o /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/libnode.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/histogram/libhistogram.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/uvwasi/libuvwasi.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/v8_gypfiles/libv8_libplatform.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/icu/libicui18n.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/zlib/libzlib.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/llhttp/libllhttp.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/cares/libcares.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/uv/libuv.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/nghttp2/libnghttp2.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/brotli/libbrotli.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/deps/openssl/libopenssl.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/v8_gypfiles/libv8_base_without_compiler.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/icu/libicuucx.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/icu/libicudata.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/v8_gypfiles/libv8_libsampler.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/v8_gypfiles/libv8_compiler.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/v8_gypfiles/libv8_snapshot.a /home/snek/Desktop/misc/nodejs/node/out/Release/obj.target/tools/v8_gypfiles/libv8_initializers.a -latomic -lm -ldl -Wl,--end-group

[bnoordhuis]

My guess is that -Wl,-T src/large_pages/ld.implicit.script.lld is the cause. We're passing the version of the linker script that is tailored to LLVM's lld but clang++ calls out to GNU ld.

node.gypi guards on llvm_version!="0.0" but that's wrong because it only says something about the compiler, not the linker.

Untested but make LINK="clang++ -fuse-ld=/path/to/lld" might work.

[devsnek]

Interesting... make LINK="clang++ -fuse-ld=/usr/bin/ld.lld" works, but I had to install lld. Did something about our build config change recently?

[bnoordhuis]

Large page support is now always enabled after 8952105. Before, you had to opt in with ./configure --use-largepages.

[devsnek]

@bnoordhuis so would the fix be introducing a new gyp variable (based on clang++ -Xlinker --version or something)?

[doochik]

v12.16.0 fails to build from source with this error

[bnoordhuis]

Be patient, #31547 hasn't been released yet. Use the workaround from #31249 (comment) in the mean time.

[juanarbol]

@bnoordhuis #31547 is landed in v14.x and quite close to be released in v12.17.0, do you think that we could close this issue? Or we should wait til' v12 release?

[bnoordhuis]

I think this is good to close. There's nothing actionable, we're just waiting for the next release.