This is the mail archive of the
mailing list for the GCC project.
Re: Minimal GCC/Linux shared lib + EH bug example
- From: martin at v dot loewis dot de (Martin v. Loewis)
- To: "David Abrahams" <david dot abrahams at rcn dot com>
- Cc: "Mark Mitchell" <mark at codesourcery dot com>, "Jason Merrill" <jason at redhat dot com>, "Ralf W. Grosse-Kunstleve" <rwgk at cci dot lbl dot gov>, <gcc at gcc dot gnu dot org>
- Date: 13 May 2002 07:58:20 +0200
- Subject: Re: Minimal GCC/Linux shared lib + EH bug example
- References: <email@example.com><firstname.lastname@example.org>
"David Abrahams" <email@example.com> writes:
> > My feeling is that a user interface like this
> What do you mean by "like this"?
> > is just not worth having. It is true that these features
> Please be specific so that I can understand your position. Which are "these
Interpreting Mark: "this" is an interface that sometimes works,
> Have you read the rest of the thread? The reasons it doesn't work by
> accident have been pretty fully explored; if you're still surprised
> in light of that explanation I'd appreciate knowing why because the
> rest of us are probably missing something important.
Mark is right that you just found a special case of a more general
problem, and that what you consider a solution (do string compares)
just solves the special case, not the general problem.
static int counter = 0;
if(counter % 1000 == 0)
If this was part of the libboost headers, then, again, you would end
up with three copies of the static variable (ext1, ext2, libcore). If
ext1 is loaded first, libcore's usage is resolved to the copy in ext1,
and expansions of the inline function in ext2 would use a second copy
(the copy inside libcore would not be used). That would be equally
wrong, but impossible to fix.
Likewise for templates:
static T* singleton;
template<typename T>T* X::singleton = new T;
You would end up with up-to three copies of the singleton for any
value of T.
Your last straw is that this is a bug in the Linux dynamic loader,
since the Solaris loader behaves differently. I'm not sure exactly how
it behaves, but it probably has one of the following options:
1. resolve all weak symbols defined both in extN and libcore to
libcore. Then, anybody linking agains libcore gets the definition
of the symbols in libcore. This probably violates the symbol
resolution order of the gABI, so this likely not happens.
2. When loading ext1, resolve weak symbols defined both in ext1 and
libcore to the definition in ext1; this is what happens on Linux,
too. When loading ext2, notice that some of the symbols defined
both in ext2 and libcore have already been resolved, for those,
use the pre-existing binding; this essentially results in ext1,
ext2, and libcore sharing common symbols.
You could try to report this as a bug in the Linux dynamic linker. For
that, you probably have to construct an example that doesn't include
C++, but instead directly involves weak symbols. Of course, you should
make sure that your example "passes" on Solaris.