This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Duplicate data objects in shared libraries
----- Original Message -----
From: "Martin v. Loewis" <martin@v.loewis.de>
> "David Abrahams" <david.abrahams@rcn.com> writes:
>
> > Hmm, that's interesting and unexpected (to me). Wouldn't it cause an
error
> > in C++?
>
> Depends on what "in C++" is. In a single program, two definitions of
> the same object are an error, no diagnostics required (3.2/3;
> diagnostics is required only if both definitions are in the same
> translation unit).
>
> With static libraries, it is common to have a library definition
>
> // foo.c
> void free(void*);
>
> and allow the program to override this definition in the "main
> program". The linker, when building the program, will take the
> definition from the main program, and disregard the definition from
> the library.
...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.
> To allow the same kind of replacement in shared libraries, it is
> necessary that the static linker does not reject such duplicate
> definitions, either - let alone the dynamic linker.
...and this is expected to work on any symbol without explicit notation, I
take it, just as with static libs. Hmph; I guess that makes the behavior I
want to specify a bit simpler, though it certainly leaves the door open to
silent unreliability (though it would be considerably less-open).
> > > I somewhat lost track as to what your problem is, though: earlier,
you
> > > said you accept that static members of class templates might be
> > > duplicated at run-time, and that your problem is only with things you
> > > cannot control (such as typeinfo objects).
> >
> > Wait, weren't you the one who was unwilling to accept half-measures?
>
> Well, yes. Are you saying you now object because I did? That's a good
> reason, of course :-)
Because you did what? I don't think I was objecting, but if I was, it was
to what seemed to be a strange conversational gambit on your part.
If you accepted the idea of implementing a half-measure, I would be very
happy. I need a fix, and I need it sooner than we'll see any change in the
linker/loader behavior. Also, I want to point out that despite the fact
that making just RTTI and EH work properly is a half-measure, it's a
half-measure that *many* C++ implementations seem to take. I think there's
a reason for that, and that there's great value in providing behavior
consistent with other implementations (and the expectations people will
have developed based on other implementations) when practical.
> > 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 never said there was a bug (the title of this thread came from Ralf).
> > It's pretty hard to say there's a bug anywhere in the absence of a
> > specification.
>
> In that case, either everything is fine (which apparently it is not),
> or there is a bug in the specification (for not defining a behaviour
> for an apparently important case).
OK, there's a bug in one or more specifications, here.
> > Since Mr. Lu generously stepped forward and volunteered to look into
> > the implementation I'm just trying to understand enough of the
> > details so I can describe the optimal behavior to him.
>
> I see. Not to discourage you, but I believe that the current behaviour
> is quite cast in stone, so there is little chance to change it. Also,
> even if a change was made today, it would take years for that change
> to propagate to end users.
I've heard that before ;-)
I'm willing to take the long view (as long as I can also take the short
view simultaneously).
-Dave