Static linking considered harmful

[John Reiser]

Jakub Jelinek wrote:
>> On Wed, Nov 22, 2006 at 07:33:37AM -0800, John Reiser wrote:
>>
>
>>>>>>E.g. ideally we'd drop libpthread.a, librt.a, libstdc++.a, libgfortran.a,
>>>>>>libboost*.a, all GUI libs that have also *.so libs, etc.
>>
>>>>
>>>>libstdc++.a must stay in Fedora Core.  libstdc++ is not compatible AT ALL
>>>>across versions, and there are _many_.  g++ has not learned or implemented
>>>>a stable ABI (application binary interface); the "name mangling" to encode
>>>>types is not even stable yet.
>
>>
>>
>> That's simply not true.  libstdc++ is backwards ABI compatible (similarly to
>> glibc etc.) between 3.4.x/4.0.x/4.1.x/4.2.x and I don't think that will
>> change in 4.3.x either.


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.

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.

>>In FC we include older libstdc++'s (2.96-RH,
>> 3.2.x/3.3.x (those 2 were also backwards ABI compatible)) too, so unless
>> you use very old gcc, you should be just fine if you link dynamically.
>>
>>
>
>>>>Even libgcc_s has a couple more years before it can be considered stable.
>
>>
>>
>> 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.

--