symbol level versioning in shared object libraries created by gcc 3.x

symbol level versioning in shared object libraries created by gcc 3.x

[Hespelt, Steve (Exchange)]

I apologize if this is the wrong source [this link referred me to this
email address
http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Service.html#Service ] but
this issue is killing me...
I've read through the manual pages on symbol versioning but I'm still
confused...

I have a vendor's shared library foo.so [the vendor claims it was built
by gcc 3.2.0 & the nm output supports this claim] which has unresolved
references to symbols that end with @GLIBCPP_3.2. When I try to use this
vendor's library in a link command [gcc 3.2.3 ] that makes use of the
3.2.3 libstdc++.so.5.0.3 (the -v output shows the correct path), the
vendor's unresolved references are not satisfied by the corresponding
symbol in libstdc++.so - obviously because my libstdc++.so's symbols
don't have the @GLIBCPP_3.2 suffix.

Having read the http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt page, I
believe the vendor's library has symbol level versioning enabled.
However, I'm assuming this versioning must be function of the gcc
compiler as the source of the @GLIBCPP_3.2 being appended to the mangled
signature of the symbols. How does the compiler know which suffix to
apply to what symbols? I see free@@GLIBC_2.0 (makes sense to me as
free() is a C API function) while others have GLIBCPP_3.2 [these are
symbols of type U according to nm ] while still others have no suffix at
all [none of the vendor's C++ API member functions have a suffix]. 
Is there a pragma which, if present in a library's header files, causes
the suffix to be applied to the generated symbol? If my code uses a
member function of a stdc++ class, why should the generated reference
contain the suffix unless the compiler knows to or is the symbol
declaration modified in the header context to contain the suffix??
I see in c++config.h the _GLIBCPP_SYMVER not define'd in our copy [the
#undef _GLIBCPP_SYMVER is commented out] but the above questions still
remain - how does gcc know which symbols to append the @GLIBCPP_ to when
compiling my source code to object code which at run-time depends on the
symbols matching those found in libraries such as libstdc++ ?

Thanks for reading this long-winded question & for any
insights/references to how this works.
-steve


***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************

Re: symbol level versioning in shared object libraries created by gcc 3.x

[Ian Lance Taylor]

"Hespelt, Steve \(Exchange\)" <shespelt@bear.com> writes:

> Having read the http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt page, I
> believe the vendor's library has symbol level versioning enabled.
> However, I'm assuming this versioning must be function of the gcc
> compiler as the source of the @GLIBCPP_3.2 being appended to the mangled
> signature of the symbols. How does the compiler know which suffix to
> apply to what symbols? I see free@@GLIBC_2.0 (makes sense to me as
> free() is a C API function) while others have GLIBCPP_3.2 [these are
> symbols of type U according to nm ] while still others have no suffix at
> all [none of the vendor's C++ API member functions have a suffix]. 
> Is there a pragma which, if present in a library's header files, causes
> the suffix to be applied to the generated symbol? If my code uses a
> member function of a stdc++ class, why should the generated reference
> contain the suffix unless the compiler knows to or is the symbol
> declaration modified in the header context to contain the suffix??
> I see in c++config.h the _GLIBCPP_SYMVER not define'd in our copy [the
> #undef _GLIBCPP_SYMVER is commented out] but the above questions still
> remain - how does gcc know which symbols to append the @GLIBCPP_ to when
> compiling my source code to object code which at run-time depends on the
> symbols matching those found in libraries such as libstdc++ ?

The compiler does not have anything to do with symbol versioning.  In
general, symbol versions are added when the shared library is created,
by passing a version script to the linker.

I don't think you mentioned what OS you are using, but in glibc for
GNU/Linux, the version script is probably here:
    sysdeps/unix/sysv/linux/Versions

Some symbols may also get version strings from assembler code which
appears in glibc headers files.  Look at include/libc-symbols.h.

Ian

Re: symbol level versioning in shared object libraries created by gcc 3.x

[llewelly]

"Hespelt, Steve (Exchange)" <shespelt@bear.com> writes:
[snip]
> "Hespelt, Steve \(Exchange\)" <shespelt@bear.com> writes:
> 
> > Having read the http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt page,
> I
> > believe the vendor's library has symbol level versioning enabled.
[snip]

Here is a shot in the dark. Try configuring your gcc with
    --enable-symvers (in addition to your normal configure
    arguments). See
http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html .

RE: symbol level versioning in shared object libraries created by gcc 3.x

[Hespelt, Steve (Exchange)]

(Ian Lance Taylor replied to my initial message)
Thanks for replying - I've read through the gnu ld documention this
morning - especially about the use of version scripts used by ld when
creating shared libraries. What about cases where ordinary object files
have unresolved references to symbols which are defined in libstdc++ (in
the libstdc++ library these symbols have the symbol version string
suffix)? If the ordinary object file references don't have the same
suffix as part of the symbol name, won't there be a linker resolution
problem as well? I'm assuming that to avoid this problem, the generated
symbol has to have this version suffix applied and I'm guessing that it
would be done via the _GLIBCPP__ASM_SYMVER macro.

I'm using gcc-3.2.3 but cannot find a libc-symbols.h under the
installation root directory.

I've downloaded the gcc 3.2.3 source tarball & configured libstdc++-v3
under the gcc 3.2.3 source tree's root directory. I see the
src/global.cc & src/locale.cc using the above macro but unless the
globals.cc is indirectly incorporated into the compiler's translation
unit, how would the ordinary object file have the correct reference to
various symbols defined in libstdc++? Ie. If a symbol definition in
libstdc++.so has the symbol version suffix @GLIBCPP_3.2, what will force
the reference in my application's object code to also have the same
suffix so at link time the reference will be resolved?

For example, this vendor's shared library has an unresolved reference to
std::set_new_handler(void (*)() )@GLIBCPP_3.2 [according to the linker
error messages & the c++filt output when given the mangled symbol as
displayed by nm]. Unless the vendor used the same linker version script
when creating their shared library, shouldn't the std:set_new_handler
reference be missing the symbol version suffix?

I appreciate your patience with my ignorance - I'm pretty new to gcc /
libstdc++ usage and I haven't had to deal with version scripts when
dealing with Sun's CC and linker usage.
-steve
-----Original Message-----
From: Ian Lance Taylor [mailto:ian@wasabisystems.com] 
Sent: Thursday, March 25, 2004 9:02 AM
To: Hespelt, Steve (Exchange)
Cc: gcc-help@gcc.gnu.org
Subject: Re: symbol level versioning in shared object libraries created
by gcc 3.x

"Hespelt, Steve \(Exchange\)" <shespelt@bear.com> writes:

> Having read the http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt page,
I
> believe the vendor's library has symbol level versioning enabled.
> However, I'm assuming this versioning must be function of the gcc
> compiler as the source of the @GLIBCPP_3.2 being appended to the
mangled
> signature of the symbols. How does the compiler know which suffix to
> apply to what symbols? I see free@@GLIBC_2.0 (makes sense to me as
> free() is a C API function) while others have GLIBCPP_3.2 [these are
> symbols of type U according to nm ] while still others have no suffix
at
> all [none of the vendor's C++ API member functions have a suffix]. 
> Is there a pragma which, if present in a library's header files,
causes
> the suffix to be applied to the generated symbol? If my code uses a
> member function of a stdc++ class, why should the generated reference
> contain the suffix unless the compiler knows to or is the symbol
> declaration modified in the header context to contain the suffix??
> I see in c++config.h the _GLIBCPP_SYMVER not define'd in our copy [the
> #undef _GLIBCPP_SYMVER is commented out] but the above questions still
> remain - how does gcc know which symbols to append the @GLIBCPP_ to
when
> compiling my source code to object code which at run-time depends on
the
> symbols matching those found in libraries such as libstdc++ ?

The compiler does not have anything to do with symbol versioning.  In
general, symbol versions are added when the shared library is created,
by passing a version script to the linker.

I don't think you mentioned what OS you are using, but in glibc for
GNU/Linux, the version script is probably here:
    sysdeps/unix/sysv/linux/Versions

Some symbols may also get version strings from assembler code which
appears in glibc headers files.  Look at include/libc-symbols.h.

Ian


***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************