Created attachment 1473654 [details] Tarball with minimal testcase. Description of problem: Linker fails to resolve explitcitly referenced versioned symbol from an external DSO when building and linking an executable with LTO (-flto / -Wl,-flto) enabled. Doing the same with GCC everything works as expected. Version-Release number of selected component (if applicable): clang-6.0.1-1.fc28 clang version 6.0.1 (tags/RELEASE_601/final) Target: x86_64-unknown-linux-gnu Thread model: posix How reproducible: 100% (see attached testcase) Steps to Reproduce: 1. Run `make` from testcase (use GCC, works). 2. Run `make clean`. 3. Run `CC=clang make` (use Clang). 4. *BANG* Actual results: Linker fails to resolve the explicitly referenced symbol from DSO. Expected results: Works, as when using GCC. Additional info: source.c:LINENO: undefined reference to `foo@BAR_123' /usr/bin/ld: out.a: No symbol version section for versioned symbol `foo@BAR_123' /usr/bin/ld: final link failed: Nonrepresentable section on output DSO symbols when built using Clang: $nm -gD --with-symbol-versions --special-syms libtestcase.so 0000000000000000 A BAR_123@@BAR_123 0000000000000000 A BAR_234@@BAR_234 w __cxa_finalize.5 00000000000005e0 T foo@BAR_123 00000000000005f0 T foo@@BAR_234 w __gmon_start__ w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable DSO symbols when built using GCC: $nm -gD --with-symbol-versions --special-syms libtestcase.so 0000000000000000 A BAR_123@@BAR_123 0000000000000000 A BAR_234@@BAR_234 w __cxa_finalize.5 00000000000005f0 T foo@BAR_123 00000000000005e0 T foo@@BAR_234 w __gmon_start__ w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable (The start addresses of the functions differ in GCC build with LTO.) I suspect the problem comes from the LLVMgold / libLTO plugin for ld. Fedora 28+ is affected, too.
Version-Release number of selected component (if applicable): clang-6.0.1-1.fc28 clang version 6.0.1 (tags/RELEASE_601/final) Target: x86_64-unknown-linux-gnu Thread model: posix binutils-2.29.1-23.fc28 GNU ld version 2.29.1-23.fc28 llvm-libs-6.0.1-1.fc28
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
Still valid for Rawhide.
The bug has been fixed upstream - I cannot reproduce it with top-of-tree llvm version. I'll check if It's fixed in 7.0.1 that has just been released to rawhide and is in pending for f29.
Bug fixed on f29 with clang 7.0.0.
The bug was exactly fixed by this commit https://reviews.llvm.org/rL329651 @tstellar: should we backport that fix?
Yes, let's backport this to llvm-6.0.1 in f28.
Unfortunately the patch would introduce API/ABI break, so we'd rather not apply the patch and don't fix this bug. considering f28 is at the end of its lifetime and that the bug is fixed in f29, this seems to be a reasonnable choice. For reference, the patch was: https://src.fedoraproject.org/rpms/llvm/pull-request/7