Re: Version of shared libs Vs Name mangling.

[LLeweLLyn Reese <llewelly at lifesupport dot shutdown dot com>]

"Ajay Bansal" <Ajay_Bansal at infosys dot com> writes:

> Can I know, with which version of gcc a binary has been built???

Not really. If the executable is dynamicly linked, was written in C++,
    and uses the C++ standard library, run ldd on the executable. You
    should see something like the following:


[llewelly at localhost cc_moderated_examples]$ ldd ./a.out
        libstdc++.so.5 => not found
        libm.so.6 => /lib/libm.so.6 (0x40026000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40048000)
        libc.so.6 => /lib/libc.so.6 (0x40052000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

The line you are looking for is the one of the form 'libstdc++.so.X'
    where X is 2,3,4,5 . In this case it happens to be the first line,
    but don't count on that; if the executable uses a shared library,
    (say, gtkmm) which uses the standard c++ library, that will
    typically come before libstdc++.

If X is 5, the application was linked against the gcc 3.2 library,
    and was in all likelyhood compiled by 3.2 .

    libstdc++.so.5 => comes with gcc 3.2
    libstdc++.so.4 => comes with gcc 3.1
    libstdc++.so.3 => comes with gcc 3.0 *or* gcc 2.96
    libstdc++.so.2 => comes with gcc 2.95

That's partly from memory; I've only got 3.2, 3.1, and 2.96, so the so
    numbers for 3.0 and 2.95 may be different from what I list.

(Yes, I know the a.out in the example above will not execute due to
    libstdc++.so.5 not being found, but that isn't relevant.)

> -----Original Message-----
> From: Ajay Bansal 
> Sent: Thursday, March 06, 2003 12:40 PM
> To: gcc-help at gcc dot gnu dot org
> Subject: Version of shared libs Vs Name mangling.
> 
> 
> Hi All
> 
> Pleeeeeeeeeeease help me out.. (otherwise I am sure to get some hard
> thrashing)
> 
> I am working on RH73, gcc version 3.2.1.
> 
> I have a binary which is dependent on xercec-c libraries. My code uses a
> function XMLException.
> 
> Now there are different versions of libxerces-c available. In version
> 1.5.1 this symbol is mangled as __12XMLException
> 
> While in the version 2.1.0, it is mangled as 
> _ZTI12XMLException

hm.

[llewelly at localhost cc_moderated_examples]$/usr/local/gcc-3.2.2/bin/c++filt
_ZTI12XMLException
typeinfo for XMLException
__12XMLException
XMLException::XMLException(void)

The above is me feeding those two symbols to the c++filt that comes
    with gcc 3.2.2 . c++filt demangles c++ symbols. The first is a
    typeinfo node, and the second is a function. So in the first case,
    you've mis-identified the symbol. I suggest you read the info
    pages for nm and c++filt.

> Now, initially my code was using 2.1.0 version of shared lib. But due to
> some problems (beyond reach of normal developers like me), we had to
> shift to 1.5.1. I built my product using 1.5.1 version. But while
> testing, in the test environment libraries of both versions were
> present. [:(:(:( ].

> 
> So the above symbol was picked from 2.1.0 libxerces-so.lib. But now when
> the final package is sent out for testing, it does not have any 2.1.0
> libs. Now we get the "undefined symbol error".. :(
> 
> I have to stick to 1.5.1. how can I resolve this error????

Take 2.1.0 out of your development environment.