This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Common handling of Sun/GNU symbol versioning


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]