egcc 1.1.2 outputs global object constructors as local (C static) symbols

[Martin v. Loewis]

> I want to understand. I can fix it myself anyway but would like to
> understand what the problem was ...

Sure. When picking a name for the _GLOBAL_.I.* function, gcc follows
that rule:

a) if there is a global non-static symbol defined, use that
b) if no such symbol is defined, make up an arbitrary one, based on
   the file name and some other random magic

In the past, we had a number of reports that this clashed in case b):
People had global objects in a file foo.cc, and they had two files
with that name in their project. So when linking, the linker
complained about duplicate symbols.

As a work-around, we improved the random magic. It is now less likely
to clash, but there is still a chance that it does.

After 1.1.1, we also got reports about duplicate symbols in case a),
and that was more severe. That was supposed to be fail-safe, because
of the one-definition-rule. It turns out that people often break this
rule with dynamically-loaded shared libraries. They have the same
global symbol in different shared libraries. As long as they don't
reference that symbol, everything is OK.

In that case, gcc used the same symbol twice as the global ctor
name. It turned out that the dynamic loader would then initialize one
object twice, and the other not at all. This is a serious problem, and
the only solution is to make the initializer symbols .local.

> Side remarks : when you are building embbedded system written in C++,
> trust me, that you do not want to let the linker make things behing 
> your back and that the "system" crt0 has nothing to do with application
> crt0...
> 
> So, I hope you realize that you may not have the FULL picture of C++
> use in mind despite the tone of your mail

I was expecting something like that (embedded systems). I think I
would have been more verbose initially when you had indicated why you
were following that approach, and not only what the approach was.

I still think it is the wrong approach. i586-pc-linux-gnu (or whatever
Linux target you appear to use) is what C++ calls a 'hosted'
environment, whereas you seem to be targetting a 'freestanding'
environment. gcc is well-suited for freestanding environments, you
just have to define what its properties are. 

gcc is also very good at cross-compilation. However, creating objects
for one target and then using it on another is not guaranteed to work.

Regards,
Martin