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, it 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.