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

[Martin v. Loewis]

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

People had any reason to expect this to work, so they used that
feature. They made a case that the problem is real, and the binutils
people told that the problem is real, so it was fixed.

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

I think you can get at them using dlsym.

> 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

I think this is the common case these days ... the kernel is often
compiled with gcc 2.7.2, and the compiler for applications is
egcs. Having more than one compiler installed if you cross-target is
typical, not special.

> ... Is there a way to gracefully control "global initializer"
> instanciation?

Depends on the definition of "gracefully". If the target defines
ASM_OUTPUT_CONSTRUCTOR, then the symbol is not public.

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

I'm not sure. objcopy has --localize-symbol.

Martin