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:
> > When I added the initializer as you suggest, the "C" language example
> > produces the same results as the C++ one.
> And not surprisingly so. Still, to make you better understood, I
> recommend that you:
> a) put all object files into a single directory,
> b) in the C-only case (weak.tgz), drop the path to gcc - this has
>    nothing to do with a specific gcc release
> c) drop the usage of C99 features in main.c (declare all variables
>    at top)
> d) if you want to keep the template example in the discussion:
>    drop the path to g++ (it's not specific for a g++ release, either)

Thanks, I'll take all of your suggestions and post some new examples.

> [it turns out that you can also drop the __attribute__((weak)) in the
> C example; it does not contribute to the behaviour]

Hmm, that's interesting and unexpected (to me). Wouldn't it cause an error
in C++?

> 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? Heh,
that appears to have been you

    "What good would be it be if you are happy, but the next user
    complains that all his counters are incorrect?"

> Why are static members of template classes suddenly a problem?

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

> Also, where do you suspect the bug now? GCC? glibc? Python? Your own
> code?

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

I *am* convinced that the current behavior of ELF shared libraries with g++
is suboptimal.
I also think I know what an optimal behavior (within the "spirit of the
current design" -- not making it look like Windows or anything) looks like.
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.


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