libgcc
This page provides a summary of discussions about the pros and cons
of distributing 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.
Issues
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:
- Shared objects must be linked against
libgcc, just as
main programs must be, in order to provide a variety of run-time
support.
- If two shared objects (or one shared object and a main program)
are linked against different versions of
libgcc havoc
may ensue. In particular, entry points with the same name in
different versions of libgcc may operate in different
ways.
- To this end, a shared library version of
libgcc
should 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
libgcc is present in any given program.
Unfortunately, there are negative consequences as well:
The dynamic linker must be able to find libgcc.
If libgcc is not installed in /lib,
/usr/lib, or a similar automatically searched
location, LD_LIBRARY_PATH, or its equivalent, will
have to be explicitly set.
(Note that this problem already exists with
libstdc++.so, making 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
linker.)
The usual concerns about shared library versioning apply. A
program linked against libgcc.1.2.so may not work
with 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 libgcc used
when compiling the program is newer than the version of
libgcc present on the target system.
Conclusions
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 libgcc and
will require shared library vendors to distribute new versions of
their libraries.
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 libgcc, such
as the C library on a Solaris system, say.)
C library vendors should not make libgcc a
part of the C library. Doing so will mean that using a new version
of GCC, which requires a newer version of libgcc,
but linking against the same C library, would be impossible. (Of
course, if some kind of linker magic can be done so that the
version of 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.
Please send FSF & GNU inquiries & questions to
gnu@gnu.org.
There are also other ways
to contact the FSF.
These pages are maintained by
the GCC team.
For questions related to the use of GCC, please consult these web
pages and the GCC manuals. If
that fails, the gcc-help@gcc.gnu.org
mailing list might help.
Please send comments on these web pages and the development of GCC to our
developer mailing list at gcc@gnu.org
or gcc@gcc.gnu.org. All of our lists
have public archives.
Copyright (C) Free Software Foundation, Inc.,
51 Franklin St, Fifth Floor, Boston, MA 02110, USA.
Verbatim copying and distribution of this entire article is
permitted in any medium, provided this notice is preserved.
|
Last modified 2006-06-21
|
|