Multiple definition of static constexpr data member with C++11 and 17

Florian Weimer fweimer@redhat.com
Mon Aug 16 15:48:52 GMT 2021


* Jonathan Wakely:

> On Mon, 16 Aug 2021 at 13:47, Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Jonathan Wakely:
>>
>> > On Mon, 16 Aug 2021 at 10:59, Florian Weimer wrote:
>> >>
>> >> * Jonathan Wakely via Gcc-help:
>> >>
>> >> > I'm not sure if GCC should change, or if the linker should be changed
>> >> > to permit a single non-weak non-UNIQUE definition to be merged with
>> >> > zero or more UNIQUE definitions. As a workaround you can compile the
>> >> > C++17 code with -fno-gnu-unique so that GCC uses a weak symbol, but
>> >> > that isn't a good solution in general (the unique binding exists for
>> >> > good reasons).
>> >>
>> >> What are those reasons, exactly?
>> >
>> > I think it was added to ensure uniqueness of static objects across
>> > libraries opened with RTLD_LOCAL.
>>
>> Hmm, that makes some sense.  The glibc implementation is not really
>> structured in such a way that it is obvious that this is the goal.
>> (glibc knows what it has loaded, so it could search just that, and not
>> construct a separate hash table.)
>>
>> >> I've been trying to find a rationale and specification of
>> >> STB_GNU_UNIQUE, but have not been successful.
>> >>
>> >> The glibc implementation does not handle symbol versions, it ignores
>> >> them.  It's not entirely clear to me if this is a bug.
>> >
>> > Does anybody use it with more than one symbol version though?
>>
>> libstdc++?
>
> There are no symbols in libstdc++ that exist with multiple versions.

I think someone complained that a versioned libc++ had a symbol clash
with libstdc++ through STB_GNU_UNIQUE symbols.

I can't find that bug report right now though. 8-(

Thanks,
Florian



More information about the Gcc-help mailing list