From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 46659385AE62; Sun, 19 Jun 2022 08:15:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 46659385AE62 From: "ishitatsuyuki at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/105933] LTO ltrans object files does not have proper st_bind and st_visibility Date: Sun, 19 Jun 2022 08:15:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 12.1.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ishitatsuyuki at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2022 08:15:02 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105933 --- Comment #2 from Tatsuyuki Ishi --- Created attachment 53164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D53164&action=3Dedit 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 ltr= ans object to ld directly. It will give you a duplicate symbol error. Exact com= mand line attached below. $ ld --build-id --eh-frame-hdr --hash-style=3Dgnu -m elf_x86_64 -dynamic-li= nker /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=20 ld: /usr/lib/libboost_fiber.a(condition_variable.o):(.tbss._ZGVZN5boost6fibers6= detail13spinlock_ttas4lockEvE9generator[_ZGVZN5boost6fibers6detail13spinloc= k_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._ZZN5boost6fibers6de= tail13spinlock_ttas4lockEvE9generator[_ZZN5boost6fibers6detail13spinlock_tt= as4lockEvE9generator]+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.=