This page provides a summary of discussions about the pros and cons
libgcc as a shared library, as well as a
static library. In addition this page details the plans regarding
libgcc for the GCC 3.0 release.
Richard Henderson provided an excellent summary of the issues in a mail message posted to the GCC mailing lists. For maximum convenience, that message is paraphrased here:
libgcc, just as main programs must be, in order to provide a variety of run-time support.
libgcchavoc may ensue. In particular, entry points with the same name in different versions of
libgccmay operate in different ways.
libgccshould be persuaded. All shared objects, and programs linked dynamically, should link against the shared version of
libgcc. That will ensure that only one version of
libgccis present in any given program.
Unfortunately, there are negative consequences as well:
The dynamic linker must be able to find
libgcc is not installed in
/usr/lib, or a similar automatically searched
LD_LIBRARY_PATH, or its equivalent, will
have to be explicitly set.
(Note that this problem already exists with
libgcc a shared
object is probably no worse for C++ programs than the existing
situation. Similar considerations apply to other
language-specific run-time libraries; when created as shared
libraries, such libraries must be made available to the dynamic
The usual concerns about shared library versioning apply. A
program linked against
libgcc.1.2.so may not work
libgcc.1.1.so. Therefore, shared library
vendors may wish to distribute new versions of
libgcc along with their shared libraries; users
will have to decide whether or not to upgrade their
libgcc when this occurs. Even distributors of
ordinary programs may be forced to distribute new versions of
libgcc if the version of
when compiling the program is newer than the version of
libgcc present on the target system.
There is no real choice. It must be possible for shared libraries
built with different versions of
libgcc to work
together well. Therefore, a shared version of
libgcc will be distributed with GCC 3.0.
However, all possible efforts should be made to minimize user
impact. Therefore, system vendors should distribute
libgcc as an easily upgradable package, just as they
do with other libraries. The GCC development team should avoid
making changes to
libgcc wherever possible, especially
when such changes affect external interfaces. And, at all costs,
no changes should be made that remove functionality or entry points
present in earlier versions of
libgcc; doing so will
require bumping the major version number on
will require shared library vendors to distribute new versions of
A static version of
libgcc will still be built, and
should be used for statically linked programs. (The static version
might also be usable for programs whose only dynamic linkage is to
shared libraries that do not link against
as the C library on a Solaris system, say.)
C library vendors should not make
part of the C library. Doing so will mean that using a new version
of GCC, which requires a newer version of
but linking against the same C library, would be impossible. (Of
course, if some kind of linker magic can be done so that the
libgcc in the C library is disregarded in
this case, then perhaps it would be reasonable to include
libgcc in the C library.
The GNU C library project needs to be made aware of these conclusions, as they may need to take actions that facilitate this policy in new versions of the GNU C library.
Copyright (C) Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.