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

[Ian Lance Taylor <ian@wasabisystems.com>]

"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