This is the mail archive of the
mailing list for the GCC project.
Re: Duplicate data objects in shared libraries
From: "Jason Merrill" <email@example.com>
> >>>>> "David" == David Abrahams <firstname.lastname@example.org> writes:
> > One thing we didn't discuss in detail was what should happen in case
> > of a library's dependencies are already loaded, each with its own
> > definition for some shared symbol S.
> A.so -> T.so
> -> U.so
> B.so -> U.so
> ? Here, if T and U both define S, refs in U will resolve to the copy in
> but refs in B won't, so we get the same problem. Hmm.
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?
> This problem would be solved if T were to link against U, or vice versa,
> if both were linked against a third library which defined S.
> The problem is that RTLD_LOCAL really wants a strict delineation of
> provider and user;
At the RTLD_LOCAL boundary there already is a strict delineation.
> if a DSO uses a symbol from a DSO that it doesn't
> depend on, this premise is violated, and users will get confused.
I don't see the potential for confusion (leaving aside unloading for the
moment), since matching symbols in T and U above were required to be
identical anyway according to the ODR.
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
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.
> 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
If you believe Martin, symbols we care about like RTTI info and template
static members are not weak... so I don't understand the relevance of 7.
Could you describe how it would play out in practice?
> Actually, I'd be inclined to adopt the second sentence for all cases, not
> just RTLD_LOCAL. If a library provides a weak definition of something,
> the executable provides a weak definition as well, it makes sense to me
> use the library version. Doing so would improve the usefulness of
> -Wl,--gc-sections (once it works).
> Anyway, adopting this proposal, T and U would each use their own
> definition, A would use the one from T, and B would use the one from U.
> the problem would come when trying to, say, throw from U into A.
> It's not difficult to imagine this sort of situation arising with
> vague-linkage entities that are emitted when needed. For example: a
> library V defines a non-polymorphic class J but doesn't use its RTTI
> T and U link against V and both throw objects of type J. A catches the
> thrown in T, but not the one thrown in U. We would have been fine if the
> RTTI node had been emitted in V, but it wasn't needed, so it wasn't
> I don't see any way to get ld.so to just give us the semantics we want
> this subcase.
What about just following the semantics I had assumed you'd get anyway