On Wed, Nov 22, 2006 at 09:11:07AM -0800, John Reiser wrote: > It is true. Dynamic linking to libstdc++.so is a recipe for disaster in > a program that intends to be portable, because there have been bugs in the > backwards compatibility, and there is no intention of forwards compatibility. > Even some pieces of 'new' and 'delete' do not work across different > g++/libstdc++ versions because the name mangling changed. This is > particularly true for programs that [attempt to] support dynamically-loaded > runtime plugin modules. In practice this almost certainly fails if the plugin > uses a different version of g++/libstdc++ than the base program, because > simultaneous use of two (or more!) different versions of libstdc++ > by the same process breaks. Each of the various libstdc++.so thinks > that it is the only one, and so does not coordinate with the others. Plugins are a separate issue, by definition those are dynamically linked and -Bstatic -lstdc++ -Bdynamic plus symver script to hide the stuff isn't the right answer. One of the reasons is that e.g. libstdc++.a isn't -fpic, so linking it into a plugin is highly undesirable if at all possible. For plugins the simplest answer is "don't write plugins in C++ unless it is a plugin for a C++ project where everything already uses some one libstdc++", or libstdc++so7's versioned namespaces. > Speaking of glibc, even that has had compatibility problems. > For instance, in history the character classification and translation > facilities islower, isupper, tolower, toupper have had incompatible usage > of external symbols with "ctype" in the name. For example, see this thread: > http://groups.google.com/group/comp.os.linux.development.apps/browse_thread/thread/3cb7d8fbf9d82d7b/7e0fb89e71747406?lnk=st&q=ctype+group%3Acomp.os.linux.development.apps&rnum=3#7e0fb89e71747406 > Also, there have been libc.so compatibility bugs with symbol visibility of the > high precision timers used by ld-linux to measure its own performance. ctype wasn't in any way a compatibility problem. glibc is even in that regard backwards compatible (though not forwards, as with dozens of other symbols) and never guarantees ABI compatibility if you compile against one glibc and link against a different one - only binaries and shared libraries can count on backwards compatibility. > > Care to share the details? libgcc_s is symbol versioned and is backwards > > compatible. In FC we try to backport libgcc_s additions even from newer > > gcc's than the one shipped, so e.g. current GCC 4.1.x-RH libgcc_s > > has even all of GCC_4.2.0 stuff in it (and will add GCC_4.3.0 stuff soon). > > The unwinding code for DWARF2 is not compatible between libgcc_s 3.2.x > and libgcc_s 4.y. The bugs are different, so user code that calls the > unwinders, and insists on working despite the bugs, must adapt according > to which version is being used. True binary compatibility sometimes > means bug-for-bug compatibility, because sometimes the runtime language > support has not caught up to the user code. I'd argue that apps shouldn't work around unwinder bugs, instead they should be simply reported and the vendors should fix them. Certainly that's far better than e.g. having two or more unwinders within one process. Jakub -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
