[Bug libstdc++/110572] New: ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[Bug libstdc++/110572] New: ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[arndtthomas at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

            Bug ID: 110572
           Summary: ld.lld: error: duplicate symbol:
                    std::type_info::operator==(std::type_info const&)
                    const
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arndtthomas at gmx dot de
  Target Milestone: ---

Created attachment 55489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55489&action=edit
example to reproduce the error

I've filed the issue since it's a problem with libstdc++/tinfo.o.
It seems there is a missing inline if macro __GXX_TYPEINFO_EQUALITY_INLINE is
unset or set to 1.

It happens if clang is used under mingw-w64 in combination with the libstdc++
(msys2 default).
Since gcc defines the macro explicitly (built-in) to
_GXX_TYPEINFO_EQUALITY_INLINE=0 (see gcc/config/i386/cygming.h).
Clang doesn't define this macro at all, so it gets defined within typeinfo
while compiling user code. Thus there are one operator== defined within tinfo.o
and another within the user archive.

During linking the following error pops up:

ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info
const&) const
>>> defined at ../../../../libstdc++-v3/libsupc++/tinfo.cc:38
>>>            libstdc++.a(tinfo.o)
>>> defined at libclang_lld_error.a(comp_unit.o)
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)

Here is the full example to reproduce:
https://github.com/msys2/MINGW-packages/issues/17730

I fully agree, it's a issue which is more related to mingw-w64 and clang but
the root cause is unfortunately the libstdc++.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I would argue that the root cause is that Clang does not conform to the
platform ABI for mingw-w64, which requires __GXX_TYPEINFO_EQUALITY_INLINE=0 to
be defined.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Target Milestone|---                         |12.4
   Last reconfirmed|                            |2023-07-06
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |ABI

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Prior to r12-6266-g3633cc54284450 making the definition in tinfo.cc inline
would have meant it is never emitted into tinfo.o (unless __attribute__((used))
was added to it).

Since the __equal alias, the operator== definition is always used, so it will
still generate a symbol even if it's an inline function. But I'm not sure
adding 'inline' there will actually fix anything. I still see it produce the
same symbol whether inline or not:

0000000000000000 T _ZNKSt9type_info7__equalERKS_
0000000000000000 T _ZNKSt9type_infoeqERKS_

I'm also concerned that the __equal function could end up in infinite
recursion. If you compile C++20 code then the inline definition of
type_info::operator== in the header is used, which calls type_info::__equal,
which is an alias for type_info::operator==. If the alias doesn't bind locally
then it could call the inline definition from the header again, and recurse.

I think a better fix would be to declare the operator== in the header with
__attribute__((__always_inline__)). That will ensure there is never a symbol
emitted for that inline definition, and so no multiple definition errors.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
N.B. this can be reproduced without clang, just by using -std=c++20
-static-libstdc++

/usr/bin/x86_64-w64-mingw32-ld:
/home/jwakely/gcc/mingw/lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../x86_64-w64-mingw32/lib/../lib/libstdc++.a(tinfo.o):
in function `std::type_info::operator==(std::type_info const&) const':
/home/jwakely/src/gcc/build-mingw64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsupc++/tinfo.cc:61:
multiple definition of `std::type_info::operator==(std::type_info const&)
const';
/tmp/ccmMqprE.o:/home/jwakely/gcc/mingw/x86_64-w64-mingw32/include/c++/13.0.1/typeinfo:194:
first defined here
collect2: error: ld returned 1 exit status

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[arndtthomas at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

--- Comment #4 from Thomas Arndt <arndtthomas at gmx dot de> ---
Sounds good, I would agree on your solution as well. So since it's not related
to clang and can be reproduced with gcc is there a fix planned?

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[peter0x44 at disroot dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

peter0x44 at disroot dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter0x44 at disroot dot org

--- Comment #5 from peter0x44 at disroot dot org ---

#include <typeinfo>
int main() { return typeid(0) == typeid(0); }

The following reproduces for me, although strangely only with -std=c++23 and
-static-libstdc++.

x86_64-w64-mingw32-g++ test.cpp -static-libstdc++ -std=c++20
// no error

x86_64-w64-mingw32-g++ test.cpp -static-libstdc++ -std=c++23
/usr/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld:
/usr/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libstdc++.a(tinfo.o):
in function `std::type_info::operator==(std::type_info const&) const':
/build/mingw-w64-gcc/src/gcc/libstdc++-v3/libsupc++/tinfo.cc:42: multiple
definition of `std::type_info::operator==(std::type_info const&) const';
/tmp/ccyAJVlk.o:test.cpp:(.text$_ZNKSt9type_infoeqERKS_[_ZNKSt9type_infoeqERKS_]+0x0):
first defined here

Related issue:
https://github.com/skeeto/w64devkit/issues/86