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: Minimal GCC/Linux shared lib + EH bug example

"David Abrahams" <> 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
> features"?

Interpreting Mark: "this" is an interface that sometimes works,
sometimes doesn't.

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


inline void
  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:

template<typename T>
class X{
  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.


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