[Bug ld/28040] New: libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=28040 Bug ID: 28040 Summary: libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin Product: binutils Version: 2.37 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: tbaeder at redhat dot com Target Milestone: --- This is a forward of https://bugzilla.redhat.com/show_bug.cgi?id=1954375 and https://reviews.llvm.org/D104230 ld.bfd (or rather libbfd I think) creates tons of fds and passes them to the claim_file() callback that ld plugins implement. This is the case for archives as far as I can see. ld does not close the fd after the claim_file() callback has been called when the LLVM plugin is in use, but does close them when the gcc plugin is used (there is a comment about this in ld/plugin.c. Simply removing that comment and the surrounding if statement fixed the problem for me. Explicitly calling release_input_file() in LLVM's claim_file implementation also worked for me. I don't have a smaller test case for this unfortunately. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28040] libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=28040 --- Comment #2 from Timm Bäder --- On Fedora 34, in a fresh LLVM checkout on the main branch, I can reproduce this via: CC=clang CXX=clang++ cmake ../llvm -GNinja -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_ENABLE_LTO=ON The build eventually fails with: /usr/bin/ld: cannot find lib/libLLVMSupport.a: Too many open files /usr/bin/ld: cannot find lib/libLLVMTarget.a: Too many open files /usr/bin/ld: cannot find -lpthread /usr/bin/ld: cannot find lib/libLLVMAArch64Desc.a: Too many open files /usr/bin/ld: cannot find lib/libLLVMAArch64Info.a: Too many open files /usr/bin/ld: cannot find lib/libLLVMAArch64Utils.a: Too many open files etc. I'm not sure what's different to your cmake invocation though. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28040] libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=28040 --- Comment #3 from Timm Bäder --- Oh, I forgot: The binutils I have installed is 2.35.1-41 (which seems to be the latest build for F34) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28040] libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=28040 --- Comment #5 from Timm Bäder --- # /usr/bin/ld --version GNU ld (GNU Binutils) 2.36.50.20210702 Copyright (C) 2021 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Just installed from binutils master, LLVM build also fails. This time it happened while trying to link the bin/llvm-gsymutil. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28040] libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=28040 --- Comment #10 from Timm Bäder --- I had problems when installing a new master checkout of binutils system-wide, but applying that patch to a 2.36.1 checkout and installing the rpm for that works and lets me compile LLVM with clang, ld.bfd and LTO enabled. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28622] New: Common symbol version information wrong in ld.bfd-linked library
https://sourceware.org/bugzilla/show_bug.cgi?id=28622 Bug ID: 28622 Summary: Common symbol version information wrong in ld.bfd-linked library Product: binutils Version: 2.35.2 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: tbaeder at redhat dot com Target Milestone: --- Using this reproducer script: #!/bin/sh echo '.globl foo' > foo.s echo '.comm foo,1,1' >> foo.s # foo version in lib1.so is Base gcc -shared -fPIC -o lib1.so foo.s objdump -T lib1.so | grep foo # foo's version in lib2.so is now "" gcc -shared -fPIC -o lib2.so -L. -l1 foo.s objdump -T lib2.so | grep foo foo's version in lib1.so ends up being "Base". This reproducible with ld.bfd, lld and gold. However, foo's version in lib2.so ends up being "" (no version information given). That *only* reproduces with ld.bfd and not with lld or gold. Using the latter two, foo's version is Base in lib2.so as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28622] Common symbol version information wrong in ld.bfd-linked library
https://sourceware.org/bugzilla/show_bug.cgi?id=28622 --- Comment #2 from Timm Bäder --- Ok, with current ld.bfd from the master branch, I get lib1.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: w D *UND* Base _ITM_deregisterTMCloneTable w D *UND* Base__gmon_start__ w D *UND* Base _ITM_registerTMCloneTable w DF *UND* GLIBC_2.2.5 __cxa_finalize 4019 gDO .bss 0001 Basefoo for the lib1.so. With the 2.35.2 installed on my system, the first three symbols had no version information. And the output for lib2.so is exactly the same. Looks like this is already fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28622] Common symbol version information wrong in ld.bfd-linked library
https://sourceware.org/bugzilla/show_bug.cgi?id=28622 Timm Bäder changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Timm Bäder --- Got further confirmation from LLD upstream that everything is as it should be with newer binutils. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
