This is the mail archive of the
mailing list for the GCC project.
Re: Duplicate data objects in shared libraries
"David Abrahams" <firstname.lastname@example.org> writes:
> ...as a language extension, right. And some implementations require that a
> symbol be specifically labelled as eligible for such replacement by
> programs, in order to better detect errors.
For C++, it's an extension. For C, 184.108.40.206 specifies
8. All external object and function references are
resolved. Library components are linked to satisfy
external references to functions and objects not
defined in the current translation. All such
translator output is collected into a program image
which contains information needed for execution in its
So while it may be an extension to allow programs to define functions
from the standard library, a conforming implementation clearly must
support this feature for other libraries.
> ...and this is expected to work on any symbol without explicit notation, I
> take it, just as with static libs.
Atleast for malloc, it is clearly necessary to support replacements
that have been defined without any explicit notation, yes.
I now recall the reason for glibc to define all library entry points
as weak, even though the dynamic linker would not reject duplicate
symbols: with that setup, it is possible to define the replacement
malloc in a shared library that happens to be searched *after* the C
library, and to replace malloc even in shared libraries that have not
been linked with the replacement at all.
> If you accepted the idea of implementing a half-measure, I would be
> very happy.
It will be very difficult to convince GCC maintainers to change RTTI
matching, unless problem reports with that semantics pile up
significantly. I believe the rationale is that you can gain speed with
the current implementation, and that giving up that advantage in
favour of providing a minority of users with the illusion of a
solution is not acceptable.
> I need a fix, and I need it sooner than we'll see any change in the
> linker/loader behavior.
Implement your own exception matching, then. Don't rely on the C++
polymorphic exception handling, instead, define a single exception
class that carries all exceptions. Then provide library functions to
perform a more specific matching.
I believe that the notational inconvenience of that approach would be
small, and it would improve portabibility of your code.
> > > For my particular application, they are not. However, *you*
> > > convinced me that nobody was interested in solving my particular
> > > problem, and that developing useful and consistent shared
> > > library semantics for the whole language was a worthwhile goal
> > > (I also have that goal for the standardization process).
> > Good. I was just surprised by this change in mind.
> I'm surprised that you view it as a change. I'll refrain from pointing you
> at my earlier messages like
> http://gcc.gnu.org/ml/gcc/2002-05/msg00995.html<wink> which describe my
> position, but I thought what I wrote was pretty unambiguous.
I don't like these "he said, then I said" games, but in this message,
You seem to be operating on the assumption that users of shared
libraries will expect them to be semantically equivalent to
good-ol'-static linking under all circumstances ...
Of course, nobody but the most naive users have that expectation.
It appears that you are now expecting that static members in templates
behave like they do in static libraries. Does that make you a most