After the recent flurry of patches to implement Sun symbol versioning
for the GCC runtime libraries
PATCH: Support Sun symbol versioning in libstdc++-v3
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01001.html
PATCH: Support Sun symbol versioning in libgomp
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01003.html
PATCH: Support Sun symbol versioning in libgfortran
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01004.html
PATCH: Support Sun symbol versioning in libjava
[outstanding pending a final investigation]
PATCH: Support Sun symbol versioning in libssp
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01005.html
two issues remain:
* Investigate and possibly implement symbol versioning for the remaining
unversioned runtime libraries. The investigation part is currently in
progress:
Defining a libffi.so.4 ABI
http://gcc.gnu.org/ml/gcc/2010-02/msg00339.html
Defining a libobjc.so.2 ABI
http://gcc.gnu.org/ml/gcc/2010-02/msg00340.html
Defining a libgnat.so, libgnarl.so ABI
http://gcc.gnu.org/ml/gcc/2010-02/msg00341.html
* Before proceeding to an implementation, it seems useful to investigate
possible routes to do so. It seems silly to just duplicate the
current slightly different Autoconf macros and Makefile.am fragments
over and over again. They already differ in capabilities, and simply
cry for unification. I can see two, possibly staged, ways of doing
so:
** A first step would be to unify inside GCC, i.e. move to a common
implementation in the form of, say, a set of Autoconf macros
(e.g. config/symver.m4) and a Makefile.am fragment
(config/symver.mk). It seems mostly possible to do so by
parameterizing the current copies, with two caveats: the tests differ
in their method: some just check for GNU ld being present at an
appropriate version, resp. Sun ld, which implements symbol versioning
since Solaris 2.5. Others actually try to compile and link a small
test program with a mapfile and check for linker errors. I wonder if
the latter approach is really necessary, since I very much suppose
that the facilities of any version of Sun or GNU ld wrt. symbol
versioning have always been a superset of the requirements of the GCC
runtime libs.
This step seems rather straightforward, though some legwork is
required.
** On the other hand, one needn't stop here. It seems to me that
support for symbol versioning might be useful outside of GCC. In
fact, libtool already has two similar facilities: the -export-symbols
resp. -export-symbols-regex switches are a poor man's form of
controlling symbol visibility, though in a much simpler way.
Actually, the darwin and darwin-export versioning styles in libstdc++
are pretty much the same, though with a dynamically generated export
list. Not having any Windows experience, it seems that the win32-dll
LT_INIT option might be something similar.
Though proper symbol versioning is restricted to ELF platforms, at
least GNU/Linux with GNU ld and Solaris 2 with either GNU or Sun ld
(and perhaps other ELF platforms like the various BSDs, though I
don't know for sure) and is thus pretty much platform specific, it
nonetheless seems useful to provide the capability directly in
libtool to promote its use. I don't really have an idea if the
maintainers deem something like this acceptable, so before even
considering this route and designing an interface, I'd like to hear
from them what they think about something like this.
Thoughts, comments?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
