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_thre...
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