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

[VALETTE Eric]

>>>>> "Martin" == Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

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

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

For me this is a bug in the dynamic library design (name space polution that
should be solved using namespace...) and I do not see why it should propagate 
to gcc generation code. 

Anyway, they then have duplicate symbols that are hardly usable when both 
symbols are referenced (I may miss something because I know very little 
about dynamic linker technic). 


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

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

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

However, we would like to use the *same* compiler for compiling the
system and applications. Think about having a compiler for linux kernel 
and another for applications... Is there a way to gracefully control 
"global initializer" instanciation?

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

Thanks for this concrete/informative answer. Side question more related to
binutils. Is there a way to parse a fully resolved binary (not located) 
and change the symbol type from local to global?

Have a nice day,

-- eric