* Jonathan Wakely: > On Mon, 16 Aug 2021 at 13:47, Florian Weimer <fweimer@xxxxxxxxxx> 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
