Bob Rossi <bob@xxxxxxxxxx> writes: > 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)? If the shared object is dynamically linked against libstdc++.so, then the dynamic linker will look for a libstdc++.so to satisfy that requirement. If the only one it finds is the system one, then it will link that one into the process. If the shared object requires symbols with versions which are not present in the libstdc++.so that the dynamic linker finds, then the dynamic linker will report a version dependency error. In short, yes, you will get the same errors. > 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. On a sufficiently new system, it will work if you have the same version of libgcc and libstdc++ statically linked into your executable and your shared object. "Sufficiently new" means that the linker supports the --eh-frame-hdr and that the compiler uses it when linking. You can detect this by seeing whether readelf -l on your executable and shared library shows a GNU_EH_FRAME program header. Ian
