Hi, I'm attempting to make a binary release of a C++ application on Linux that was compiled with g++. As soon as I tried this release on different platforms, I found errors like this, /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found /lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.7' not found I now understand that building the binary with newer libraries isn't the ideal solution. With that in mind, I will link against an older GLIBC. I also decided it might be a good idea to link the C++ libraries statically, since that would simply remove the dependency on the C++ library. My program consists of a C++ executable, and a few C++ shared object libraries that are loaded at runtime with dlopen. I use the -static-libgcc and I link in the libstdc++.a library statically when I create the executable. When I create the shared object library, I do not use the -static-libgcc option and I link in the libstdc++.so library dynamically. Thanks for reading this far, I have a few questions now. -- The shared object has a dependency on libstdc++.so. When I open it with dlopen from the statically linked executable, will the dynamic linker grab all the libstdc++ symbols from the executable (and avoid a dependency on the system libstdc++.so shared object file) or will it just pull in the system libstdc++.so (thus giving me the initial C++ link errors in the first place)? -- My next question involves throwing C++ exceptions across shared object files. The documentation for -static-libgcc says, There are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared libgcc. The documentation describes that throwing exceptions across shared object libraries require a dynamic libgcc. Is this true, even if the statically linked executable (both -static-libgcc and static libstdc++.a) and the shared object files (dynamic libgcc and libstdc++.a) are guarenteed to be compiled with the same libgcc and libstdc++? I distribute the executable and the shared object libraries together. I have complete control over this. I wasn't clear if the dynamically loaded shared object files should be linked with either a static libgcc, a static libstdc++, both static or neither. For now they are both dynamic, and things seem to work OK on the system I built them on. Any advice would be really appreciated. Thanks, Bob Rossi
