Re: symbol versioning

[Phil Edwards <phil at jaj dot com>]

On Fri, Feb 08, 2002 at 03:30:26PM -0800, Benjamin Kosnik wrote:
> 
> What steps have you taken so far? 

The cha-cha, the tango, and the sp- oh.  Nevermind.

Mimicking the libgcc setup as close as possible (but no closer) seems to be
the safest route.  For examples, look in the gcc srcdir, at libgcc-std.ver,
config/libgcc-glibc.ver, and mklibgcc.in.

I've edited src/Makefile.am as follows (text continues later):


Index: src/Makefile.am
===================================================================
RCS file: /home/pme/Repositories/GCC/gcc/libstdc++-v3/src/Makefile.am,v
retrieving revision 1.102
diff -u -3 -r1.102 Makefile.am
--- src/Makefile.am     15 Dec 2001 07:05:03 -0000      1.102
+++ src/Makefile.am     8 Feb 2002 20:27:04 -0000
@@ -1,6 +1,7 @@
 ## Makefile for the src subdirectory of the GNU C++ Standard library.
 ##
-## Copyright (C) 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
+## Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002
+## Free Software Foundation, Inc.
 ##
 ## This file is part of the libstdc++ version 3 distribution.
 ## Process this file with automake to produce Makefile.in.
@@ -77,9 +78,20 @@
        ../libmath/libmath.la @libio_la@ \
        ../libsupc++/libsupc++convenience.la

-libstdc___la_LDFLAGS = -version-info @libtool_VERSION@ -lm
-
-libstdc___la_DEPENDENCIES = $(libstdc___la_LIBADD)
+# Remove the version-script arg to make an unversioned library.
+libstdc___la_LDFLAGS = -version-info @libtool_VERSION@ -lm \
+                       -Wl,--version-script=linker.map
+
+libstdc___la_DEPENDENCIES = $(libstdc___la_LIBADD) linker.map
+
+# For libgcc, they use all kinds of tests for how to invoke nm and awk.
+NM=../../../binutils/nm-new
+linker.map: ${top_srcdir}/symbols.ver ${libstdc___la_OBJECTS}
+       { ${NM} -pg .libs/*.o ../libmath/.libs/libmath.a \
+            ../libsupc++/.libs/libsupc++convenience.a; \
+            echo '%%'; cat ${top_srcdir}/symbols.ver; \
+       } | awk -f ${top_srcdir}/../gcc/mkmap-symver.awk > tmp-$@
+       mv tmp-$@ $@


 # Use special rules for the deprecated source files so that they find

===================================================================

(The NM setting assumes a unified tree.  There's logic for this already in
the very top-level makefile, but when you're invoking make in the library
objdir directly, that doesn't take effect.)


The objdir/src/linker.map file is built from two pieces.  There's a awk
script that is used by libgcc; so far I've been able to use the same script.
There's also a controlling version/symbol file, which I've called symbols.ver
and left at the top of the library srcdir.

It's this file that's going to be a PITA, due to name mangling and just
the sheer number of symbols to handle.  I grunted out a steaming pile of
shell script called "build_initial_list" which attempts to accumulate the
existing symbols.  For libgcc the list can be built by visual inspection;
it's a few pages long.  For us, it's a tad larger:

    11% ls -l symbols.ver
    -rw-r--r--    1 pme      pme        881268 Feb  8 16:09 symbols.ver
    12% wc -l symbols.ver
      13356 symbols.ver
    13%

although it's not actually that big:  the script collects each symbol,
and adds a commented line with the demangled name, for human inspection.
Also, the script isn't very good about only writing symbols which we
/define/, right now it tends to drop in the occasional weak reference.
Finally, to help me debug the script, it's also writing the name of the
file which generates the symbol.

The build_initial_list script runs through a finished build tree, examining
object files.  Once we get symbols.ver under control, the script should no
longer be used.  As with libgcc, we'll have to maintain the file by hand,
or at least with the help of smarter scripts; generating it from scratch
is too hit-and-miss.


I'm working on a bug regarding type_info and operators new/delete.
(That's a lie.  I'm leaving to go see a film with friends.  Over the
weekend I'll resume working on said bug.)  Once the script is debugged to
the point where it isn't utterly brain-damaged, I'll post it.  (Or check
it in, but I don't honestly think it'll be that useful in the long term.)


Phil