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. That is, we have foo@GLIBCXX_3.4.x and bar@GLIBCXX_3.4.y but we never have foo@GLIBCXX_3.4.y or bar@GLIBCXX_3.4.z
