Summary: | net-libs/nodejs-13.6.0 with sys-devel/binutils' ld.gold - ld: error: .../work/node-v13.6.0/src/large_pages/ld.implicit.script:10:10: syntax error, unexpected STRING | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Frömmel <cfroemmel> |
Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | 1i5t5.duncan, dragan.kasler, dschridde+gentoobugs, esigra, fabio.coatti, herrtimson, jasmin+gentoo, johu, marien.zwart, mike, sarnex |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://github.com/nodejs/node/issues/31249 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 269315 | ||
Attachments: |
build log
nodejs-13.6.0.ebuild-ld.gold.patch nodejs-13.6.0.ebuild-ld.gold.patch net-libs:nodejs-13.6.0:20200108-204921.log.xz |
Description
Christopher Frömmel
2020-01-08 11:38:19 UTC
Please attach the entire build log to this bug report. Created attachment 602774 [details]
build log
ld.gold does not support "INSERT", only ld.bfd does. It might work if you could get it to use the llvm/lld linker script instead: src/large_pages/ld.implicit.script.lld. This is automagically configured in node.gypi from line 316-323. But yeah, binutils-config --linker considered harmful. (In reply to Marek Bartosiewicz from comment #4) > But yeah, binutils-config --linker considered harmful. Why is that? This option appears to have disappeared from binutils-config-5.2 (despite the comments at commit bd195f1e0d49e664119adb29100dbd7a094bd008 in the portage git tree which makes no mention of dropping '4. via 'binutils-config --linker''). Not everything I build (including kernel from git) is done within the portage environment and therefore configurable via package.env; and the ability to manually select the non-default (for me) ld.bfd for things that don't support it is really useful. E.g. 'make menuconfig' for a kernel configuration (I know that genkernel.conf allows setting the linker for the actual build). I have 2597 packages on my system at the moment of which only 35 are excepted in package.env while three absolutely seem to require temporarily setting the system default to ld.bfd via 'binutils-config --linker': dev-lang/fpc, media-libs/libdv, and sys-fs/fuse. Sorry if this is a bit off-topic :-) (In reply to Adrian Bassett from comment #5) > (In reply to Marek Bartosiewicz from comment #4) > > But yeah, binutils-config --linker considered harmful. > > Why is that? Please just ignore that remark. Created attachment 602802 [details, diff]
nodejs-13.6.0.ebuild-ld.gold.patch
Could you please try this patch, please?
Created attachment 602804 [details, diff]
nodejs-13.6.0.ebuild-ld.gold.patch
Or rather this one.
Comment on attachment 602804 [details, diff]
nodejs-13.6.0.ebuild-ld.gold.patch
Found some CPU time for this issue. It ends in tears:
x86_64-pc-linux-gnu-g++ -o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/cctest -pthread -rdynamic -m64 -Wl,-z,noexecstack -Wl,--whole-archive /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/tools/v8_gypfiles/libv8_snapshot.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,-z,now -Wl,-T /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/src/large_pages/ld.implicit.script -pthread -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--start-group /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/src/node_snapshot_stub.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/src/node_code_cache_stub.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/gtest/gtest-all.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/gtest/gtest_main.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/node_test_fixture.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_aliased_buffer.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_base64.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_base_object_ptr.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_node_postmortem_metadata.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_environment.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_linked_binding.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_per_process.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_platform.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_traced_value.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_util.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_url.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_inspector_socket.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_inspector_socket_server.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/cctest/test/cctest/test_report_util.o /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/libnode.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/deps/histogram/libhistogram.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/deps/uvwasi/libuvwasi.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/tools/v8_gypfiles/libv8_libplatform.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/deps/llhttp/libllhttp.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/deps/brotli/libbrotli.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/deps/uv/libuv.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/tools/v8_gypfiles/libv8_base_without_compiler.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/tools/v8_gypfiles/libv8_libsampler.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/tools/v8_gypfiles/libv8_compiler.a /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/tools/v8_gypfiles/libv8_snapshot.a
/home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/obj.target/tools/v8_gypfiles/libv8_initializers.a -lz -luv -lcares -lnghttp2 -lcrypto -lssl -licui18n -licuuc -licudata -lm -ldl -Wl,--end-group
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/cctest: section .tbss._ZN2v88internal12trap_handler21g_thread_in_wasm_codeE lma 0x1ba78f0 adjusted to 0x1ba78f8
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/cctest: section .tbss._ZN2v88internal4wasm12_GLOBAL__N_123current_code_refs_scopeE lma 0x1ba78f0 adjusted to 0x1ba78fc
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS): in function `__libc_csu_init':
/home/portage/sys-libs/glibc-2.29-r7/work/glibc-2.29/csu/elf-init.c:86: undefined reference to `__init_array_start'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /home/portage/sys-libs/glibc-2.29-r7/work/glibc-2.29/csu/elf-init.c:86: undefined reference to `__init_array_end'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/cctest: hidden symbol `__init_array_end' isn't defined
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make: *** [cctest.target.mk:197: /home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out/Release/cctest] Error 1
rm 9b618608d1836b86d89bfa1177c55f98dcf5ad7d.intermediate 8d4d4fd8099490bb1c411491e03d2eaab3ab9f32.intermediate d72a3078e7785df8935aac9322b213abaddb011f.intermediate 8c42cd33c4f5575ff535a73ba612b012bb58984f.intermediate
make: Leaving directory '/home/jer/portage/net-libs/nodejs-13.6.0/work/node-v13.6.0/out'
* ERROR: net-libs/nodejs-13.6.0::gentoo failed (compile phase):
* emake failed
Created attachment 602912 [details] net-libs:nodejs-13.6.0:20200108-204921.log.xz (In reply to Jeroen Roovers from comment #8) > Created attachment 602804 [details, diff] [details, diff] > nodejs-13.6.0.ebuild-ld.gold.patch For reference, this is the build log with the linker script switched as per attachment #602804 [details, diff] and with C/CXXFLAGS+=-fuse-ld=gold. Maybe I simply forgot a step and maybe it should work after all. Ah, but we set this in the ebuild, too: GYP_DEFINES="linux_use_gold_flags=0 And in tools/v8_gypfiles/toolchain.gypi, linux_use_gold_flags==1 is checked for and that sets: 'ldflags': [ '-fuse-ld=gold', ], 8-\ Is there a solution for this issue? I'm unable to emerge either net-libs/nodejs-13.6.0 nor net-libs/nodejs-13.7.0, with or without the appended patch. I've worked around it by building with clang and linking with ld.lld I already had an env set up for building chromium so I reused that https://github.com/FireBurn/PortageStuff/blob/master/env/clango3lto.conf There are other examples if you don't want LTO or O3 I confirm proper merge of 13.7.0 with env/clang: CC=clang CXX=clang++ LDFLAGS="${CFLAGS} -Wl,-O1 -Wl,--as-needed -fuse-ld=lld" AR=llvm-ar NM=llvm-nm RANLIB=llvm-ranlib and package.env: net-libs/nodejs clang ...of course. Thanks! :-) (In reply to Rainer HIhn from comment #13) > Is there a solution for this issue? > > I'm unable to emerge either net-libs/nodejs-13.6.0 nor > net-libs/nodejs-13.7.0, with or without the appended patch. [FWIW, initially I simply masked 13.6 and stayed on 13.5 until I had more time to look into it. I had more time and there were more hints for a minimal workaround on this bug when I tried 13.7. So...] Akin comment #15 but more minimal workaround, two files: /etc/portage/package.env/ldflags.no.gold: # references /etc/portage/env/* # 2020.0123 doesn't like gold #704966 (CCed) ~net-libs/nodejs-13.7.0 pkg.env/ldflags.no.gold /etc/portage/env/pkg.env/ldflags.no.gold: LDFLAGS="${LDFLAGS} -fuse-ld=bfd" (Usage notes: package.env functionality covered in the portage (5) manpage. Adjust filenames as desired and package atoms as required. For me, individual functional-change-named files are most useful here, with a comment including the date, a bug number, and whether it's my bug or I'm simply CCed. That makes it easier to remember the issue and clean up if it's fixed or extend the covered version numbers at the next package update if not, later.) (In reply to Duncan from comment #16) > LDFLAGS="${LDFLAGS} -fuse-ld=bfd" toolchain-funcs.eclass has a helper function, tc-ld-disable-gold, to deal with exactly this scenario. The ebuild just needs to use it. (In reply to Jan Psota from comment #15) > I confirm proper merge of 13.7.0 with env/clang: > CC=clang > CXX=clang++ > LDFLAGS="${CFLAGS} -Wl,-O1 -Wl,--as-needed -fuse-ld=lld" > AR=llvm-ar > NM=llvm-nm > RANLIB=llvm-ranlib > > and package.env: > net-libs/nodejs clang > > ...of course. Thanks! :-) This may be true with older versions of clang, but when I use llvm/clang/lld-11, I am getting the same failure as when using gold. Still present in =net-libs/nodejs-13.7.0-r1 Iade Upstream just closed https://github.com/nodejs/node/issues/31520 via https://github.com/nodejs/node/commit/938abd9535663d45a8ec88d5fa6acc0af8e8fd13. It probably does not fix the issue that the build system ignores $LD in at least one case, but it makes nodejs-13.7.0-r1 build on my system. (In reply to Dennis Schridde from comment #20) > https://github.com/nodejs/node/commit/ > 938abd9535663d45a8ec88d5fa6acc0af8e8fd13 I confirm that the linked patch solves the problem for me. Placing it in /etc/portage/patches/net-libs/nodejs-13.7.0/ works perfectly. The good news is that net-libs/nodejs-13.8.0 no longer fails with gcc/gold. The bad news is that it still fails with llvm/clang/lld-11. Oh well, better luck next time ... (In reply to cyrillic from comment #22) > The good news is that net-libs/nodejs-13.8.0 no longer fails with gcc/gold. 13.8.0 still fails with gcc/gold here, but the same workaround, using bfd via package.env as in comment #16, continues to function. (I deliberately limit package.env workarounds to specific versions so as to have some idea when there's a fix/workaround in-tree and I can delete my package.env workaround.) Still present in =net-libs/nodejs-13.8.0 too... Iade The patch in comment #20 applies cleanly to 13.8.0 and resolves the build error (with Gold). Patch is no longer necessary to build net-libs/nodejs-13.9.0 with Gold. |