"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
