https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105933
--- Comment #2 from Tatsuyuki Ishi <ishitatsuyuki at gmail dot com> --- Created attachment 53164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53164&action=edit A source that fails to link when ltrans is grabbed separatedly and passed to link Here's a minimized test case from the linked mold issue for the purpose of reproducing the issue. For normal LTO usage, it compiles fine with `g++ main.cpp /usr/lib/libboost_fiber.a /usr/lib/libboost_context.a -flto`. We now add `-save-temps` to grab a copy of the ltrans output. Then, we grab the command line used to link through `-v`, then pass the ltrans object to ld directly. It will give you a duplicate symbol error. Exact command line attached below. $ ld --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../.. a.ltrans0.ltrans.o /usr/lib/libboost_fiber.a /usr/lib/libboost_context.a -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/crtn.o ld: /usr/lib/libboost_fiber.a(condition_variable.o):(.tbss._ZGVZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator[_ZGVZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator]+0x0): multiple definition of `guard variable for boost::fibers::detail::spinlock_ttas::lock()::generator'; a.ltrans0.ltrans.o:(.tbss+0x8): first defined here ld: /usr/lib/libboost_fiber.a(condition_variable.o):(.tbss._ZZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator[_ZZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator]+0x0): multiple definition of `boost::fibers::detail::spinlock_ttas::lock()::generator'; a.ltrans0.ltrans.o:(.tbss+0x0): first defined here To ensure successful resolution with GNU_UNIQUE TLS symbols, you need either WEAK symbols or COMDAT groups. GCC ltrans contains neither. When used with the LTO plugin, it inherits the weak st_bind from IR objects, and passes through the fallback WEAK symbols based resolution for duplicate C++ definitions (we usually use COMDAT). When you don't have the LTO plugin, boom, it's a GLOBAL symbol vs UNIQUE symbol which is a conflict without question.
