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

"David Abrahams" <> 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.

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.

> > 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 :-)

> 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 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).

> 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.


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