(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@xxxxxxxxxxxxxxxxx] Sent: Thursday, March 25, 2004 9:02 AM To: Hespelt, Steve (Exchange) Cc: gcc-help@xxxxxxxxxxx Subject: Re: symbol level versioning in shared object libraries created by gcc 3.x "Hespelt, Steve \(Exchange\)" <shespelt@xxxxxxxx> 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. ***********************************************************************
