Re: Static linking considered harmful

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux