This is the mail archive of the
mailing list for the GCC project.
Re: Duplicate data objects in shared libraries
>>>>> "David" == David Abrahams <email@example.com> writes:
> From: "Jason Merrill" <firstname.lastname@example.org>
>> A.so -> T.so
>> -> U.so
>> B.so -> U.so
> No, that's not what I had in mind. In fact I assumed *** that B would get
> the same copy of S that was currently used by U, which is to say the one in
> T. Is there any reason it couldn't work that way?
Because the one in T is not visible when we are loading B. The symbols
used to satisfy relocs in U are not re-exported by U.
> What I had in mind was more like this:
> A.so -> T.so
> B.so -> U.so
> Now there are two shared spaces (A,T) and (B,U), each with its own copy of
> S. Then:
> C.so -> T.so, U.so
> C wanted a single shared copy but ends up having to choose one or error. I
> vote for the former.
In this case, T and U are already resolved when we load C, so they already
resolve to their own copies. Under current Linux semantics, C would then
resolve to its own copies; my proposals would cause it to refer to the one
Under my proposal #7, your example and mine would have the same result.
>> I would further clarify my proposal #6 thus:
>> 7) Resolution of a relocation in a DSO loaded with RTLD_LOCAL only
>> considers definitions in the DSO itself and its dependencies. If a
>> strong definition is seen in the normal breadth-first search of these
>> DSOs, it is used; otherwise, a weak definition is chosen by depth-first
> If you believe Martin, symbols we care about like RTTI info and template
> static members are not weak...
I'm not sure that Martin said that; in any case, it's wrong. Symbols with
vague linkage are emitted as weak in order to avoid multiple definition
errors in static links.
>> I don't see any way to get ld.so to just give us the semantics we want
>> for this subcase.
> What about just following the semantics I had assumed you'd get anyway
Well, that's another possibility.
8) #7, but also consider the prior resolutions of relocs to the same symbol
in a dependency.
This would fix my example, but not yours. And I don't think it's as clean
a design as #7 alone.