Global constructor mangling

Global constructor mangling

[Simon Gittins]

Hi 

I would like to know how gcc mangles the following types of symbols:

#objdump -tC <library>
....
....
000000xxxxxxx           l     F      .text                global
constructors keyed to OS_TLI.cpp0xYLka 
....
....

In particular, I would like to produce the same mangled name on a number of
different hosts (it is a requirement that we are able to build a piece of
software identically on a number of internally managed hosts).

Both hosts run gcc 2.95.3 under gnu/linux.

I am unsure why they are not producing the same binaries.  Both hosts have
the source tree located in the same place, and use the same build process to
make the binaries.  

In a large library (I'm building libACE), it looks like these (there are
only about 20 'global constructors keyed to ...' symbols) are the only ones
that differ between the binaries produced by the two hosts.

Please CC me any reply.

Thanks in advance
Simon Gittins

Re: Global constructor mangling

[bjorn rohde jensen]

Hi Simon,

 The name mangling scheme is pretty much a compiler
implementation issue, so i would question the wisdom
of an organization placing certain requirements on it:)
If you really want to know, how it is done in gcc/g++,
i guess, you could get involved in the development of
gcc....
 I am a bit puzzled, that the same version of g++ on
identical hosts would name mangle differently. I have
not experienced that sort of thing before.

Yours sincerely,

Bjorn

Re: Global constructor mangling

[Alexy Khrabrov]

GCC 3.1 says it has a new mangling scheme.  In fact, code compiled
with g++ 2.95.3 doesn't link to g++ 3.1 libraries in a usual way.

I wonder whether I can instruct the (new?) linker to link old code
with the new libstdc++?  Is it at all possible?  Or do I have to recompile
my whole Linux dustribution?  :-)

Cheers,
Alexy

Re: Global constructor mangling

[bjorn rohde jensen]

Hi Alexy,

 Part of the idea behind name mangling is to
protect against accidentally linking incompatible
object files together, so it is certainly best, if
you make sure, you are using C++ object files
generated by 1 and only 1 compiler. Plain C code is
more forgiving, so you probably dont need to
recompile the entire distributions system libraries,
which really would be a pain;) This is my experience
at least.
 One can not take successful linkage as a guarantee
of much besides no unresolved symbols, just like
successful compilation does not ensure code sanity:)

Yours sincerely,

Bjorn

RE: Global constructor mangling

[Simon Gittins]

Hi Bjorn

>  The name mangling scheme is pretty much a compiler
> implementation issue, so i would question the wisdom
> of an organization placing certain requirements on it:)

I agree completely :)

It's a regulatory requirement (not imposed by us), and it has proved rather
difficult to get it changed.  The only thing going in our favour is that we
supply the verification PC, so we can configure our build box identically to
the verification box.  

The offending symbols all appear to be statically instantiated objects in
dynamic libraries.  

Running gcc -E on the files in question gives identical results.

Both boxes have identical gcc drivers programs, specs, and gcc-lib contents
(collect2,cc1plus etc).

> If you really want to know, how it is done in gcc/g++,
> i guess, you could get involved in the development of
> gcc....

It may be my only choice.  I'll see if I can get my head around the mangling
code in the gcc source.

Best Regards
Simon