This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Duplicate data objects in shared libraries

----- Original Message -----
From: "Martin v. Loewis" <>

> "David Abrahams" <> writes:
> > Hmm, that's interesting and unexpected (to me). Wouldn't it cause an
> > 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. 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,
> > > 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
> > 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<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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]