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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux