[build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

[Please keep me on the Cc:, I'm not subscribed to libstdc++.]

This is a revised version of

	PATCH: Support Sun symbol versioning in libstdc++-v3
	http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01001.html

which hopefully addresses all comments so far.

Primary changes since then are:

* I've included a new autoconf test for a GNU style c++filt.

* I disable support for GNU style symbol renaming since the Solaris
  ld.so.1 doesn't support it and won't support it in the forseeable
  future according to the linker maintainers.  Even if GNU ld would be
  able to generate such shared objects, they don't work at runtime, so
  there's no point in including the symbols in the versions.

* The make_sunver.pl script has seen considerable hardening since and
  has successfully build the Sun-style version maps for all currently
  versioned GCC runtime libraries (libstdc++, libgomp, libgfortran,
  libjava, libssp).

I'm not yet including the baseline_version.txt files.  What I've found
so far is: they are identical for Solaris 8 and 9, both SPARC and x86.
32-bit Solaris 10 is different, but identical between SPARC and x86,
while 64-bit differs between the architectures.  Solaris 11 differs from
S10 and also between the architectures.  Before I commit the baselines,
I'd like to figure out if some of those differences can be avoided.

The patch has been bootstrapped without regressions on
i386-pc-solaris2.{8, 9, 10, 11} and sparc-sun-solaris2.{8, 9, 10, 11},
each with Sun as and GNU as.  I've also bootstrapped with GNU as and GNU
ld 2.19 (included in Solaris 11) on {i386-pc, sparc-sun}-solaris2.11,
and apart from the issue fixed by

	PATCH: Properly support Solaris 2 ABI for symbol versioning in GNU ld
        http://sourceware.org/ml/binutils/2010-02/msg00457.html

The results were identical.  A bootstrap with CVS GNU as and GNU ld
didn't work, though: gctest FAILs and (probably as a consequence) all
libjava tests hang or FAIL.  I'll have to investigate this separately,
but this issue is independent of the current patch.

Ok for mainline?

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


2010-02-19  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	config:
	* gc++filt.m4: New file.

	contrib:
	* make_sunver.pl: New file.

	libstdc++v3:
	* acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Handle sun style.
	Require GCC_PROG_GNU_CXXFILT.
	(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT): Define
	unless targetting solaris2*.
	Include ../config/gc++filt.m4.
	* configure.host (i?86-*-solaris2*): Set abi_baseline_pair.
	(sparc-*-solaris2*): Likewise.
	* src/Makefile.am [ENABLE_SYMVERS_SUN] (version_dep, version_arg):
	New variables.
	(libstdc++-symbols.ver-sun): New target.
	* configure: Regenerate.
	* config.h.in: Regenerate.
	* Makefile.in: Likewise.
	* doc/Makefile.in: Likewise.
	* include/Makefile.in: Likewise.
	* libsupc++/Makefile.in: Likewise.
	* po/Makefile.in: Likewise.
	* python/Makefile.in: Likewise.
	* src/Makefile.in: Likewise.
	* src/atomic.cc: Only define/use _GLIBCXX_ASM_SYMVER if
	_GLIBCXX_HAVE_SYMVER_RENAMING_RUNTIME_SUPPORT.
	* src/compatibility.cc: Likewise.
	* testsuite/Makefile.am (baseline_subdir): Define.
	(baseline_symbols): Use it.
	(new-abi-baseline): Likewise.
	* testsuite/Makefile.in: Regenerate.

	* config/abi/pre/gnu.ver (GLIBCXX_3.4.5): Enclose duplicates in
	#ifdef HAVE_SYMVER_RENAMING_RUNTIME_SUPPORT.
	(GLIBCXX_3.4.6): Likewise.

	* doc/xml/manual/configure.xml (--enable-symvers): Document sun
	style.
	* doc/html/manual/configure.html: Regenerate.

	* doc/xml/manual/abi.xml: Fix grammar.
	(Symbol versioning on the libstdc++.so binary): Fix mapfile path.
	(Incremental bumping of a library pre-defined macro): Fix
	c++config path.
	(Incremental bumping of a library pre-defined macro,
	_GLIBCPP_VERSION): Likewise.
	(Matching each specific C++ compiler release to a specific set of
	C++ include files): Fix acinclude.m4 path.
	(Prerequisites): Allow for Sun linker on Solaris 2.5+.
	Use proper link to Configuring.
	Fix acinclude.m4 path.
	(Checking Active): Allow for additional symbol versioning styles.
	Provide Solaris 2 example with pvs -r.
	(Bibliography): Update Linker and Libraries Guide, C++ Migration
	Guide entries.
	* doc/html/manual/abi.html: Regenerate

	gcc:
	* doc/install.texi (Prerequisites): Document Perl requirement on
	Solaris 2.
	(Specific, *-*-solaris2*): Document GNU c++filt requirement.

diff -r 54407e53229c config/gc++filt.m4
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/config/gc++filt.m4	Mon Jun 28 10:36:05 2010 +0200
@@ -0,0 +1,26 @@
+# gc++filt.m4 serial 1					-*- Autoconf -*-
+# Find an instance of GNU c++filt on PATH.
+
+dnl Copyright (C) 2010 Free Software Foundation, Inc.
+dnl This file is free software, distributed under the terms of the GNU
+dnl General Public License.  As a special exception to the GNU General
+dnl Public License, this file may be distributed as part of a program
+dnl that contains a configuration script generated by Autoconf, under
+dnl the same distribution terms as the rest of that program.
+
+dnl From Rainer Orth.
+
+# GCC_PROG_GNU_CXXFILT
+# --------------------
+# Check for GNU c++filt.
+# FIXME: Maybe need TARGET variant, though c++filt should be target
+# independent.
+AC_DEFUN([GCC_PROG_GNU_CXXFILT],
+  [AC_ARG_VAR([CXXFILT], [Location of GNU c++filt.  Defaults to the first
+    GNU version of `c++filt', `gc++filt' on PATH.])
+  AC_CACHE_CHECK([for GNU c++filt], [ac_cv_path_CXXFILT],
+    [AC_PATH_PROGS_FEATURE_CHECK([CXXFILT], [c++filt gc++filt],
+      [_AC_PATH_PROG_FLAVOR_GNU([$ac_path_CXXFILT],
+	[ac_cv_path_CXXFILT=$ac_path_CXXFILT && ac_path_CXXFILT_found=:])])])
+  CXXFILT=$ac_cv_path_CXXFILT
+])
diff -r 54407e53229c contrib/make_sunver.pl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/contrib/make_sunver.pl	Mon Jun 28 10:36:05 2010 +0200
@@ -0,0 +1,280 @@
+#!/usr/bin/perl -w
+
+# make_sunver.pl
+#
+# This script takes at least two arguments, a GNU style version script and
+# a list of object and archive files, and generates a corresponding Sun
+# style version script as follows:
+#
+# Each glob pattern, C++ mangled pattern or literal in the input script is
+# matched against all global symbols in the input objects, emitting those
+# that matched (or nothing if no match was found).
+# A comment with the original pattern and its type is left in the output
+# file to make it easy to understand the matches.
+#
+# It expects a 'nm' with the POSIX '-P' option, but everyone has one of
+# those, right?
+# It depends on the GNU version of c++filt, since it must understand the
+# GNU mangling style.
+
+use File::Glob ':glob';
+use FileHandle;
+use IPC::Open2;
+
+# Input version script, GNU style.
+my $symvers = shift;
+
+##########
+# Get all the symbols from the library, match them, and add them to a hash.
+
+my %sym_hash = ();
+
+# List of objects and archives to process.
+my @OBJECTS = ();
+
+# List of shared objects to omit from processing.
+my @SHAREDOBJS = ();
+
+# Filter out those input archives that have corresponding shared objects to
+# avoid adding all symbols matched in the archive to the output map.
+foreach $file (@ARGV) {
+    if (($so = $file) =~ s/\.a$/.so/ && -e $so) {
+	printf STDERR "omitted $file -> $so\n";
+	push (@SHAREDOBJS, $so);
+    } else {
+	push (@OBJECTS, $file);
+    }
+}
+
+# The nm command to use.
+my $nm = $ENV{'NM_FOR_TARGET'} || "nm";
+
+# Process each symbol.
+open NM,$nm.' -P '.(join ' ',@OBJECTS).'|' or die $!;
+while (<NM>) {
+    my $i;
+    chomp;
+
+    # nm prints out stuff at the start, ignore it.
+    next if (/^$/);
+    next if (/:$/);
+    # Ignore register (SPARC only), undefined and local symbols.  The
+    # symbol name is optional; Sun nm emits none for local or .bss symbols.
+    next if (/^([^ ]+)?[ \t]+[RUa-z][ \t]+ /);
+    # Ignore objects without symbol table.  Message goes to stdout with Sun
+    # nm, while GNU nm emits the corresponding message to stderr.
+    next if (/.* - No symbol table data/);
+
+    # $sym is the name of the symbol.
+    die "unknown nm output $_" if (! /^([^ ]+)[ \t]+[A-Z][ \t]+/);
+    my $sym = $1;
+
+    # Remember symbol.
+    $sym_hash{$sym}++;
+}
+close NM or die "nm error";
+
+##########
+# The various types of glob patterns.
+#
+# A glob pattern that is to be applied to the demangled name: 'cxx'.
+# A glob patterns that applies directly to the name in the .o files: 'glob'.
+# This pattern is ignored; used for local variables (usually just '*'): 'ign'.
+
+# The type of the current pattern.
+my $glob = 'glob';
+
+# We're currently inside `extern "C++"', which Sun ld doesn't understand.
+my $in_extern = 0;
+
+# We're currently inside a conditional section: just skip it.
+my $in_ifdef = 0;
+
+# The c++filt command to use.  This *must* be GNU c++filt; the Sun Studio
+# c++filt doesn't handle the GNU mangling style.
+my $cxxfilt = $ENV{'CXXFILT'} || "c++filt";
+
+# The current version name.
+my $current_version = "";
+
+# Was there any attempt to match a symbol to this version?
+my $matches_attempted;
+
+# The number of versions which matched this symbol.
+my $matched_symbols;
+
+open F,$symvers or die $!;
+
+# Print information about generating this file
+print "# This file was generated by make_sunver.pl.  DO NOT EDIT!\n";
+print "# It was generated by:\n";
+printf "# %s %s %s\n", $0, $symvers, (join ' ',@ARGV);
+printf "# Omitted archives with corresponding shared libraries: %s\n",
+    (join ' ', @SHAREDOBJS) if $#SHAREDOBJS >= 0;
+print "#\n\n";
+
+while (<F>) {
+    # End of skipped section.
+    if (/^[ \t]*\#endif/) {
+	$in_ifdef = 0;
+	next;
+    }
+
+    # Just skip a conditional section.
+    if ($in_ifdef) { next; }
+
+    # Lines of the form '};'
+    if (/^([ \t]*)(\}[ \t]*;[ \t]*)$/) {
+	$glob = 'glob';
+	if ($in_extern) {
+	    $in_extern--;
+	    print "$1##$2";
+	} else {
+	    print;
+	}
+	next;
+    }
+
+    # Lines of the form '} SOME_VERSION_NAME_1.0;'
+    if (/^[ \t]*\}[ \tA-Z0-9_.a-z]+;[ \t]*$/) {
+	$glob = 'glob';
+	# We tried to match symbols agains this version, but none matched.
+	# Emit dummy hidden symbol to avoid marking this version WEAK.
+	if ($matches_attempted && $matched_symbols == 0) {
+	    print "  hidden:\n";
+	    print "    .force_WEAK_off_$current_version = DATA S0x0 V0x0;\n";
+	}
+	print; next;
+    }
+
+    # Special comments that look like C preprocessor conditionals.
+    # Just skip the contents for now.
+    # FIXME: Allow passing in conditionals from the command line to really
+    # control the skipping.
+    if (/^[ \t]*\#ifdef/) {
+	$in_ifdef = 1;
+	next;
+    }
+
+    # Comment and blank lines
+    if (/^[ \t]*\#/) { print; next; }
+    if (/^[ \t]*$/) { print; next; }
+
+    # Lines of the form '{'
+    if (/^([ \t]*){$/) {
+	if ($in_extern) {
+	    print "$1##{\n";
+	} else {
+	    print;
+	}
+	next;
+    }
+
+    # Lines of the form 'SOME_VERSION_NAME_1.1 {'
+    if (/^([A-Z0-9_.]+)[ \t]+{$/) {
+	# Record version name.
+	$current_version = $1;
+	# Reset match attempts, #matched symbols for this version.
+	$matches_attempted = 0;
+	$matched_symbols = 0;
+	print;
+	next;
+    }
+
+    # Ignore 'global:'
+    if (/^[ \t]*global:$/) { print; next; }
+
+    # After 'local:', globs should be ignored, they won't be exported.
+    if (/^[ \t]*local:$/) {
+	$glob = 'ign';
+	print;
+	next;
+    }
+
+    # After 'extern "C++"', globs are C++ patterns
+    if (/^([ \t]*)(extern \"C\+\+\"[ \t]*)$/) {
+	$in_extern++;
+	$glob = 'cxx';
+	# Need to comment, Sun ld cannot handle this.
+	print "$1##$2\n"; next;
+    }
+
+    # Chomp newline now we're done with passing through the input file.
+    chomp;
+
+    # Catch globs.  Note that '{}' is not allowed in globs by this script,
+    # so only '*' and '[]' are available.
+    if (/^([ \t]*)([^ \t;{}#]+);?[ \t]*$/) {
+	my $ws = $1;
+	my $ptn = $2;
+	# Turn the glob into a regex by replacing '*' with '.*'.
+	# Keep $ptn so we can still print the original form.
+	($pattern = $ptn) =~ s/\*/\.\*/g;
+
+	if ($glob eq 'ign') {
+	    # We're in a local: * section; just continue.
+	    print "$_\n";
+	    next;
+	}
+
+	# Print the glob commented for human readers.
+	print "$ws##$ptn ($glob)\n";
+	# We tried to match a symbol to this version.
+	$matches_attempted++;
+
+	if ($glob eq 'glob') {
+	    my %ptn_syms = ();
+
+	    # Match ptn against symbols in %sym_hash.
+	    foreach my $sym (keys %sym_hash) {
+		# Maybe it matches one of the patterns based on the symbol in
+		# the .o file.
+		$ptn_syms{$sym}++ if ($sym =~ /^$pattern$/);
+	    }
+
+	    foreach my $sym (sort keys(%ptn_syms)) {
+		$matched_symbols++;
+		print "$ws$sym;\n";
+	    }
+	} elsif ($glob eq 'cxx') {
+	    my %dem_syms = ();
+
+	    # Verify that we're actually using GNU c++filt.  Other versions
+	    # most likely cannot handle GNU style symbol mangling.
+	    my $cxxout = `$cxxfilt --version 2>&1`;
+	    $cxxout =~ m/GNU/ or die "$0 requires GNU c++filt to function";
+
+	    # Talk to c++filt through a pair of file descriptors.
+	    # Need to start a fresh instance per pattern, otherwise the
+	    # process grows to 500+ MB.
+	    my $pid = open2(*FILTIN, *FILTOUT, $cxxfilt) or die $!;
+
+	    # Match ptn against symbols in %sym_hash.
+	    foreach my $sym (keys %sym_hash) {
+		# No?  Well, maybe its demangled form matches one of those
+		# patterns.
+		printf FILTOUT "%s\n",$sym;
+		my $dem = <FILTIN>;
+		chomp $dem;
+		$dem_syms{$sym}++ if ($dem =~ /^$pattern$/);
+	    }
+
+	    close FILTOUT or die "c++filt error";
+	    close FILTIN or die "c++filt error";
+	    # Need to wait for the c++filt process to avoid lots of zombies.
+	    waitpid $pid, 0;
+
+	    foreach my $sym (sort keys(%dem_syms)) {
+		$matched_symbols++;
+		print "$ws$sym;\n";
+	    }
+	} else {
+	    # No?  Well, then ignore it.
+	}
+	next;
+    }
+    # Important sanity check.  This script can't handle lots of formats
+    # that GNU ld can, so be sure to error out if one is seen!
+    die "strange line `$_'";
+}
+close F;
diff -r 54407e53229c gcc/doc/install.texi
--- a/gcc/doc/install.texi	Mon Jun 28 10:31:36 2010 +0200
+++ b/gcc/doc/install.texi	Mon Jun 28 10:36:05 2010 +0200
@@ -456,8 +456,13 @@
 Necessary when regenerating @file{Makefile} dependencies in libiberty.
 Necessary when regenerating @file{libiberty/functions.texi}.
 Necessary when generating manpages from Texinfo manuals.
-Necessary when targetting Darwin, building libstdc++,
+Necessary when targetting Darwin, building @samp{libstdc++},
 and not using @option{--disable-symvers}.
+Necessary when targetting Solaris 2 with Sun @command{ld}, building
+@samp{libstdc++}, and not using @option{--disable-symvers}.  A helper
+scripts needs @samp{Glob.pm}, which is missing from @command{perl} 5.005
+included in Solaris~8.  The bundled @command{perl} in Solaris~9 and up
+works.
 Used by various scripts to generate some files included in SVN (mainly
 Unicode-related and rarely changing) from source tables.
 
@@ -4131,6 +4136,12 @@
 version (2.20.1) is known to work, but generally lacks platform specific
 features, so better stay with Sun @command{ld}.
 
+To enable symbol versioning in @samp{libstdc++} with Sun @command{ld},
+you need to have any version of GNU @command{c++filt}, which is part of
+GNU binutils.  @samp{libstdc++} symbol versioning will be disabled if no
+appropriate version is found.  Sun @command{c++filt} from the Sun Studio
+compilers does @emph{not} work.
+
 Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or
 newer: @command{g++} will complain that types are missing.  These headers
 assume that omitting the type means @code{int}; this assumption worked for
diff -r 54407e53229c libstdc++-v3/acinclude.m4
--- a/libstdc++-v3/acinclude.m4	Mon Jun 28 10:31:36 2010 +0200
+++ b/libstdc++-v3/acinclude.m4	Mon Jun 28 10:36:05 2010 +0200
@@ -2812,11 +2812,14 @@
 
 GLIBCXX_ENABLE(symvers,$1,[=STYLE],
   [enables symbol versioning of the shared library],
-  [permit yes|no|gnu|gnu-versioned-namespace|darwin|darwin-export])
+  [permit yes|no|gnu|gnu-versioned-namespace|darwin|darwin-export|sun])
 
 # If we never went through the GLIBCXX_CHECK_LINKER_FEATURES macro, then we
 # don't know enough about $LD to do tricks...
 AC_REQUIRE([GLIBCXX_CHECK_LINKER_FEATURES])
+# Sun style symbol versions needs GNU c++filt for make_sunver.pl to work
+# with extern "C++" in version scripts.
+AC_REQUIRE([GCC_PROG_GNU_CXXFILT])
 
 # Turn a 'yes' into a suitable default.
 if test x$enable_symvers = xyes ; then
@@ -2834,6 +2837,20 @@
       case ${target_os} in
         darwin*)
 	  enable_symvers=darwin ;;
+	# Sun symbol versioning exists since Solaris 2.5.
+	solaris2.[[5-9]]* | solaris2.1[[0-9]]*)
+	  # make_sunver.pl needs GNU c++filt to support extern "C++" in
+	  # version scripts, so disable symbol versioning if none can be
+	  # found.
+	  if test -z "$ac_cv_path_CXXFILT"; then
+	    AC_MSG_WARN([=== You have requested Sun symbol versioning, but])
+	    AC_MSG_WARN([=== no GNU c++filt could  be found.])
+	    AC_MSG_WARN([=== Symbol versioning will be disabled.])
+	    enable_symvers=no
+	  else
+	    enable_symvers=sun
+	  fi
+	  ;;
         *)
           enable_symvers=no ;;
       esac
@@ -2846,8 +2863,26 @@
     enable_symvers=darwin
 fi
 
+# Check if 'sun' was requested on non-Solaris 2 platforms.
+if test x$enable_symvers = xsun ; then
+  case ${target_os} in
+    solaris2*)
+      # All fine.
+      ;;
+    *)
+      # Unlikely to work.
+      AC_MSG_WARN([=== You have requested Sun symbol versioning, but])
+      AC_MSG_WARN([=== you are not targetting Solaris 2.])
+      AC_MSG_WARN([=== Symbol versioning will be disabled.])
+      enable_symvers=no
+      ;;
+  esac
+fi
+
 # Check to see if 'gnu' can win.
-if test $enable_symvers = gnu || test $enable_symvers = gnu-versioned-namespace; then
+if test $enable_symvers = gnu || 
+  test $enable_symvers = gnu-versioned-namespace || 
+  test $enable_symvers = sun; then
   # Check to see if libgcc_s exists, indicating that shared libgcc is possible.
   AC_MSG_CHECKING([for shared libgcc])
   ac_save_CFLAGS="$CFLAGS"
@@ -2883,6 +2918,8 @@
       AC_MSG_WARN([=== you are not building a shared libgcc_s.])
       AC_MSG_WARN([=== Symbol versioning will be disabled.])
       enable_symvers=no
+  elif test $with_gnu_ld != yes && test $enable_symvers = sun; then
+    : All interesting versions of Sun ld support sun style symbol versioning.
   elif test $with_gnu_ld != yes ; then
     # just fail for now
     AC_MSG_WARN([=== You have requested GNU symbol versioning, but])
@@ -2922,6 +2959,11 @@
     AC_DEFINE(_GLIBCXX_SYMVER_DARWIN, 1, 
               [Define to use darwin versioning in the shared library.])
     ;;
+  sun)
+    SYMVER_FILE=config/abi/pre/gnu.ver
+    AC_DEFINE(_GLIBCXX_SYMVER_SUN, 1, 
+              [Define to use Sun versioning in the shared library.])
+    ;;
 esac
 
 if test x$enable_symvers != xno ; then
@@ -2945,8 +2987,24 @@
 GLIBCXX_CONDITIONAL(ENABLE_SYMVERS_GNU, test $enable_symvers = gnu)
 GLIBCXX_CONDITIONAL(ENABLE_SYMVERS_GNU_NAMESPACE, test $enable_symvers = gnu-versioned-namespace)
 GLIBCXX_CONDITIONAL(ENABLE_SYMVERS_DARWIN, test $enable_symvers = darwin)
+GLIBCXX_CONDITIONAL(ENABLE_SYMVERS_SUN, test $enable_symvers = sun)
 AC_MSG_NOTICE(versioning on shared library symbols is $enable_symvers)
 
+if test $enable_symvers != no ; then
+   case ${target_os} in
+     # The Solaris 2 runtime linker doesn't support the GNU extension of
+     # binding the same symbol to different versions
+     solaris2*)
+       symvers_renaming=no  ;;
+     # Other platforms with GNU symbol versioning (GNU/Linux, more?) do.
+     *)
+       AC_DEFINE(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT, 1,
+         [Define to 1 if the target runtime linker supports binding the same symbol to different versions.])
+       symvers_renaming=yes
+    esac
+fi
+GLIBCXX_CONDITIONAL(ENABLE_SYMVERS_SOL2, test $symvers_renaming = no)
+
 # Now, set up compatibility support, if any.
 # In addition, need this to deal with std::size_t mangling in
 # src/compatibility.cc.  In a perfect world, could use
@@ -3083,5 +3141,6 @@
 ])
 
 # Macros from the top-level gcc directory.
+m4_include([../config/gc++filt.m4])
 m4_include([../config/tls.m4])
 
diff -r 54407e53229c libstdc++-v3/config/abi/pre/gnu.ver
--- a/libstdc++-v3/config/abi/pre/gnu.ver	Mon Jun 28 10:31:36 2010 +0200
+++ b/libstdc++-v3/config/abi/pre/gnu.ver	Mon Jun 28 10:36:05 2010 +0200
@@ -740,6 +740,7 @@
     sqrtl;
     copysignf;
 
+#ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
    # GLIBCXX_ABI compatibility only.
     # std::string
     _ZNKSs11_M_disjunctEPKc;
@@ -767,6 +768,7 @@
     _ZNSt11char_traitsI[cw]E2eqERK[cw]S2_;
 
     _ZNSt19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEppEv;
+#endif
 
     # std::locale::Impl _M_ members
     _ZNSt6locale5_Impl16_M_install_facetEPKNS_2idEPKNS_5facetE;
@@ -875,7 +877,9 @@
 
     _ZNSt15basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EE9showmanycEv;
 
+#ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
     _ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv;
+#endif
 
     _ZN9__gnu_cxx6__poolILb1EE13_M_initializeEv;
 
diff -r 54407e53229c libstdc++-v3/configure.host
--- a/libstdc++-v3/configure.host	Mon Jun 28 10:31:36 2010 +0200
+++ b/libstdc++-v3/configure.host	Mon Jun 28 10:36:05 2010 +0200
@@ -320,7 +320,13 @@
 	;;
     esac
     ;;
+  i?86-*-solaris2*)
+    abi_baseline_pair=i386-solaris2
+    ;;
   powerpc*-*-darwin*)
     port_specific_symbol_files="\$(srcdir)/../config/os/bsd/darwin/ppc-extra.ver"
     ;;
+  sparc*-*-solaris2*)
+    abi_baseline_pair=sparc-solaris2
+    ;;
 esac
diff -r 54407e53229c libstdc++-v3/doc/xml/manual/abi.xml
--- a/libstdc++-v3/doc/xml/manual/abi.xml	Mon Jun 28 10:31:36 2010 +0200
+++ b/libstdc++-v3/doc/xml/manual/abi.xml	Mon Jun 28 10:36:05 2010 +0200
@@ -33,9 +33,9 @@
 <title>The C++ Interface</title>
 
 <para>
-  C++ applications often dependent on specific language support
+  C++ applications often depend on specific language support
   routines, say for throwing exceptions, or catching exceptions, and
-  perhaps also dependent on features in the C++ Standard Library.
+  perhaps also depend on features in the C++ Standard Library.
 </para>
 
 <para>
@@ -122,7 +122,7 @@
 releases of library binaries the ability to add new symbols and add
 functionality, all the while retaining compatibility with the previous
 releases in the series. Thus, program binaries linked with the initial
-release of a library binary will still link correctly if the library
+release of a library binary will still run correctly if the library
 binary is replaced by carefully-managed subsequent library
 binaries. This is called forward compatibility.
 </para>
@@ -232,7 +232,7 @@
     <listitem>
       <para>
 	Release versioning on the libstdc++.so binary, implemented in
-	the same was as the libgcc_s.so binary above. Listed is the
+	the same way as the libgcc_s.so binary above. Listed is the
 	filename: <constant>DT_SONAME</constant> can be deduced from
 	the filename by removing the last two period-delimited numbers. For
 	example, filename <filename>libstdc++.so.5.0.4</filename>
@@ -306,10 +306,10 @@
 
     <listitem><para>Symbol versioning on the libstdc++.so binary.</para>
 
-    <para>mapfile: libstdc++/config/linker-map.gnu</para>
+    <para>mapfile: libstdc++-v3/config/abi/pre/gnu.ver</para>
     <para>It is versioned with the following labels and version
    definitions, where the version definition is the maximum for a
-   particular release. Note, only symbol which are newly introduced
+   particular release. Note, only symbols which are newly introduced
    will use the maximum version definition. Thus, for release series
    with the same label, but incremented version definitions, the later
    release has both versions. (An example of this would be the
@@ -410,7 +410,7 @@
 
     <para>
     This macro is defined in the file "c++config" in the
-    "libstdc++/include/bits" directory. (Up to gcc-4.1.0, it was
+    "libstdc++-v3/include/bits" directory. (Up to gcc-4.1.0, it was
     changed every night by an automated script. Since gcc-4.1.0, it is
     the same value as gcc/DATESTAMP.)
     </para>
@@ -474,7 +474,7 @@
 
     <para>
     This macro is defined in the file "c++config" in the
-    "libstdc++/include/bits" directory and is generated
+    "libstdc++-v3/include/bits" directory and is generated
     automatically by autoconf as part of the configure-time generation
     of config.h.
     </para>
@@ -514,7 +514,7 @@
     All C++ includes are installed in include/c++, then nest in a
     directory hierarchy corresponding to the C++ compiler's released
     version. This version corresponds to the variable "gcc_version" in
-    "libstdc++/acinclude.m4," and more details can be found in that
+    "libstdc++-v3/acinclude.m4," and more details can be found in that
     file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before gcc-3.4.0).
     </para>
     <para>
@@ -584,7 +584,8 @@
     <para>
       Minimum environment that supports a versioned ABI: A supported
       dynamic linker, a GNU linker of sufficient vintage to understand
-      demangled C++ name globbing (ld), a shared executable compiled
+      demangled C++ name globbing (ld) or the Sun linker, a shared
+      executable compiled
       with g++, and shared libraries (libgcc_s, libstdc++) compiled by
       a compiler (g++) with a compatible ABI. Phew.
     </para>
@@ -598,7 +599,7 @@
     <para>
       Most modern Linux and BSD versions, particularly ones using
       gcc-3.1.x tools and more recent vintages, will meet the
-      requirements above.
+      requirements above, as does Solaris 2.5 and up.
     </para>
   </sect3>
 
@@ -614,7 +615,7 @@
     <para>
       For more information on configure options, including ABI
       impacts, see:
-      http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html
+      <link linkend="manual.intro.setup.configure">here</link>
     </para>
 
     <para>
@@ -623,7 +624,7 @@
     </para>
 
     <para>
-      In particular, libstdc++/acinclude.m4 has a macro called
+      In particular, libstdc++-v3/acinclude.m4 has a macro called
       GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument
       passed in via --enable-symvers=foo). At that point, the macro
       attempts to make sure that all the requirement for symbol
@@ -648,6 +649,7 @@
 </screen>
 
 <para>
+  or another of the supported styles.
   If you don't see this line in the configure output, or if this line
   appears but the last word is 'no', then you are out of luck.
 </para>
@@ -685,6 +687,23 @@
    <code>U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4</code>
 </para>
 
+<para>
+On Solaris 2, you can use <code>pvs -r</code> instead:
+</para>
+
+<programlisting>
+%g++ hello.cc -o hello.out
+
+%pvs -r hello.out
+        libstdc++.so.6 (GLIBCXX_3.4, GLIBCXX_3.4.12);
+        libgcc_s.so.1 (GCC_3.0);
+        libc.so.1 (SUNWprivate_1.1, SYSVABI_1.3);
+</programlisting>
+
+<para>
+<code>ldd -v</code> works too, but is very verbose.
+</para>
+
   </sect3>
 </sect2>
 
@@ -735,7 +754,7 @@
 <listitem><para> Adding an explicit copy constructor or destructor to a
 class that would otherwise have implicit versions. This will change
 the way the compiler deals with this class in by-value return
-statements or parameters: instead of being passing instances of this
+statements or parameters: instead of passing instances of this
 class in registers, the compiler will be forced to use memory. See <ulink url="http://www.codesourcery.com/cxx-abi/abi.html#calls"> this part</ulink>
  of the C++ ABI documentation for further details.
  </para></listitem>
@@ -920,7 +939,7 @@
 </para>
 
 <para>
-This is a proactive check the library ABI. Currently, exported symbol
+This is a proactive check of the library ABI. Currently, exported symbol
 names that are either weak or defined are checked against a last known
 good baseline. Currently, this baseline is keyed off of 3.4.0
 binaries, as this was the last time the .so number was incremented. In
@@ -955,7 +974,7 @@
 get information. However, currently this approach gives insufficient
 data for use in library testing, as class data members, their offsets,
 and other detailed data is not displayed with this flag.
-(See g++/7470 on how this was used to find bugs.)
+(See PR g++/7470 on how this was used to find bugs.)
 </para>
 
 <para>
@@ -968,7 +987,7 @@
     <title>Multiple ABI Testing</title>
 <para>
 A "C" application, dynamically linked to two shared libraries, liba,
-libb. The dependent library liba is C++ shared library compiled with
+libb. The dependent library liba is a C++ shared library compiled with
 gcc-3.3.x, and uses io, exceptions, locale, etc. The dependent library
 libb is a C++ shared library compiled with gcc-3.4.x, and also uses io,
 exceptions, locale, etc.
@@ -1114,9 +1133,9 @@
 
   <biblioentry>
     <biblioid class="uri">
-      <ulink url="http://docs.sun.com/app/docs/doc/817-1984">
+      <ulink url="http://docs.sun.com/app/docs/doc/819-0690">
 	<citetitle>
-	  Sun Solaris 2.9 : Linker and Libraries Guide (document 816-1386)
+	  Linker and Libraries Guide (document 819-0690)
 	</citetitle>
       </ulink>
     </biblioid>
@@ -1125,9 +1144,9 @@
 
   <biblioentry>
     <biblioid class="uri">
-      <ulink url="http://docs.sun.com/app/docs/doc/819-5266">
+      <ulink url="http://docs.sun.com/app/docs/doc/819-3689">
 	<citetitle>
-	  Sun Solaris 2.9 : C++ Migration Guide (document 816-2459)
+	  Sun Studio 11: C++ Migration Guide (document 819-3689)
 	</citetitle>
       </ulink>
     </biblioid>
diff -r 54407e53229c libstdc++-v3/doc/xml/manual/configure.xml
--- a/libstdc++-v3/doc/xml/manual/configure.xml	Mon Jun 28 10:31:36 2010 +0200
+++ b/libstdc++-v3/doc/xml/manual/configure.xml	Mon Jun 28 10:36:05 2010 +0200
@@ -279,8 +279,8 @@
  <listitem><para>In 3.1 and later, tries to turn on symbol versioning in the
 	shared library (if a shared library has been
 	requested). Values for 'style' that are currently supported
-	are 'gnu', 'gnu-versioned-namespace', 'darwin', and
-	'darwin-export'. Both gnu- options require that a recent
+	are 'gnu', 'gnu-versioned-namespace', 'darwin',
+	'darwin-export', and 'sun'. Both gnu- options require that a recent
 	version of the GNU linker be in use. Both darwin options are
 	equivalent. With no style given, the configure script will try
 	to guess correct defaults for the host system, probe to see if
diff -r 54407e53229c libstdc++-v3/src/Makefile.am
--- a/libstdc++-v3/src/Makefile.am	Mon Jun 28 10:31:36 2010 +0200
+++ b/libstdc++-v3/src/Makefile.am	Mon Jun 28 10:36:05 2010 +0200
@@ -45,14 +45,38 @@
 	  fi; \
 	fi
 
+CLEANFILES = libstdc++-symbols.ver
+
 if ENABLE_SYMVERS_GNU
+if ENABLE_SYMVERS_SOL2
+version_arg = -Wl,--version-script,libstdc++-symbols.ver-sol2
+version_dep = libstdc++-symbols.ver-sol2
+libstdc++-symbols.ver-sol2 : libstdc++-symbols.ver
+	sed -e '/^#ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT/,/^#endif/d' $< \
+	 > $@ || (rm -f $@ ; exit 1)
+else
 version_arg = -Wl,--version-script=libstdc++-symbols.ver
 version_dep = libstdc++-symbols.ver
 endif
+endif
 if ENABLE_SYMVERS_GNU_NAMESPACE
 version_arg = -Wl,--version-script=libstdc++-symbols.ver
 version_dep = libstdc++-symbols.ver
 endif
+if ENABLE_SYMVERS_SUN
+version_arg = -Wl,-M,libstdc++-symbols.ver-sun
+version_dep = libstdc++-symbols.ver-sun
+libstdc++-symbols.ver-sun : libstdc++-symbols.ver \
+		$(toplevel_srcdir)/contrib/make_sunver.pl \
+		$(libstdc___la_OBJECTS) $(libstdc___la_LIBADD)
+	CXXFILT="$(CXXFILT)"; export CXXFILT; \
+	perl $(toplevel_srcdir)/contrib/make_sunver.pl \
+	  libstdc++-symbols.ver \
+	  $(libstdc___la_OBJECTS:%.lo=.libs/%.o) \
+	 `echo $(libstdc___la_LIBADD) | \
+	    sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \
+	 > $@ || (rm -f $@ ; exit 1)
+endif
 if ENABLE_SYMVERS_DARWIN
 version_arg = -Wl,-exported_symbols_list,libstdc++-symbols.explist
 version_dep = libstdc++-symbols.explist
@@ -66,6 +90,8 @@
 	    sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \
 	 > $@ || (rm -f $@ ; exit 1)
 endif
+
+CLEANFILES += $(version_dep)
 else
 version_arg =
 version_dep =
diff -r 54407e53229c libstdc++-v3/src/atomic.cc
--- a/libstdc++-v3/src/atomic.cc	Mon Jun 28 10:31:36 2010 +0200
+++ b/libstdc++-v3/src/atomic.cc	Mon Jun 28 10:36:05 2010 +0200
@@ -1,6 +1,6 @@
 // Support for atomic operations -*- C++ -*-
 
-// Copyright (C) 2008, 2009
+// Copyright (C) 2008, 2009, 2010
 // Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
@@ -127,7 +127,8 @@
 // _GLIBCXX_*_SYMVER macros in this file.
 
 #if defined(_GLIBCXX_SYMVER_GNU) && defined(PIC) \
-    && defined(_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE)
+    && defined(_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE) \
+    && defined(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT)
 
 #define _GLIBCXX_ASM_SYMVER(cur, old, version) \
    asm (".symver " #cur "," #old "@@" #version);
diff -r 54407e53229c libstdc++-v3/src/compatibility.cc
--- a/libstdc++-v3/src/compatibility.cc	Mon Jun 28 10:31:36 2010 +0200
+++ b/libstdc++-v3/src/compatibility.cc	Mon Jun 28 10:36:05 2010 +0200
@@ -26,7 +26,8 @@
 #include <bits/c++config.h>
 
 #if defined(_GLIBCXX_SYMVER_GNU) && defined(PIC) \
-    && defined(_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE)
+    && defined(_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE)\
+    && defined(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT)
 #define istreambuf_iterator istreambuf_iteratorXX
 #define basic_fstream basic_fstreamXX
 #define basic_ifstream basic_ifstreamXX
@@ -201,7 +202,8 @@
 // NB: These symbols renames should go into the shared library only,
 // and only those shared libraries that support versioning.
 #if defined(_GLIBCXX_SYMVER_GNU) && defined(PIC) \
-    && defined(_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE)
+    && defined(_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE) \
+    && defined(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT)
 
 /* gcc-3.4.4
 _ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv
diff -r 54407e53229c libstdc++-v3/testsuite/Makefile.am
--- a/libstdc++-v3/testsuite/Makefile.am	Mon Jun 28 10:31:36 2010 +0200
+++ b/libstdc++-v3/testsuite/Makefile.am	Mon Jun 28 10:36:05 2010 +0200
@@ -69,8 +69,10 @@
 
 extract_symvers = $(glibcxx_srcdir)/scripts/extract_symvers
 
+baseline_subdir := $(shell $(CXX) --print-multi-dir)
+
 baseline_symbols:
-	-@(output=${baseline_dir}/baseline_symbols.txt; \
+	-@(output=${baseline_dir}/${baseline_subdir}/baseline_symbols.txt; \
 	  if test ! -f $${output}; then \
 	    echo "Baseline file doesn't exist."; \
 	    echo "Try 'make new-abi-baseline' to create it."; \
@@ -78,8 +80,8 @@
 	  fi; true)
 
 new-abi-baseline:
-	-@$(mkinstalldirs) ${baseline_dir}
-	-@(output=${baseline_dir}/baseline_symbols.txt; \
+	-@$(mkinstalldirs) ${baseline_dir}/${baseline_subdir}
+	-@(output=${baseline_dir}/${baseline_subdir}/baseline_symbols.txt; \
 	  if test -f $${output}; then \
 	    output=$${output}.new; \
 	    t=`echo $${output} | sed 's=.*config/abi/=='`; \

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Bonzini]

>        config:
>        * gc++filt.m4: New file.

This is ok.

>        contrib:
>        * make_sunver.pl: New file.

Not sure this belongs in contrib.  Probably the toplevel or, for now,
libstdc++-v3, is a better place.

>        libstdc++v3:
>        * acinclude.m4 (GLIBCXX_ENABLE_SYMVERS): Handle sun style.
>        Require GCC_PROG_GNU_CXXFILT.
>        (_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT): Define
>        unless targetting solaris2*.
>        Include ../config/gc++filt.m4.
>        * configure.host (i?86-*-solaris2*): Set abi_baseline_pair.
>        (sparc-*-solaris2*): Likewise.
>        * src/Makefile.am [ENABLE_SYMVERS_SUN] (version_dep, version_arg):
>        New variables.
>        (libstdc++-symbols.ver-sun): New target.
>        * configure: Regenerate.
>        * config.h.in: Regenerate.
>        * Makefile.in: Likewise.
>        * doc/Makefile.in: Likewise.
>        * include/Makefile.in: Likewise.
>        * libsupc++/Makefile.in: Likewise.
>        * po/Makefile.in: Likewise.
>        * python/Makefile.in: Likewise.
>        * src/Makefile.in: Likewise.
>        * src/atomic.cc: Only define/use _GLIBCXX_ASM_SYMVER if
>        _GLIBCXX_HAVE_SYMVER_RENAMING_RUNTIME_SUPPORT.
>        * src/compatibility.cc: Likewise.
>        * testsuite/Makefile.am (baseline_subdir): Define.
>        (baseline_symbols): Use it.
>        (new-abi-baseline): Likewise.
>        * testsuite/Makefile.in: Regenerate.
>
>        * config/abi/pre/gnu.ver (GLIBCXX_3.4.5): Enclose duplicates in
>        #ifdef HAVE_SYMVER_RENAMING_RUNTIME_SUPPORT.
>        (GLIBCXX_3.4.6): Likewise.
>
>        * doc/xml/manual/configure.xml (--enable-symvers): Document sun
>        style.
>        * doc/html/manual/configure.html: Regenerate.
>
>        * doc/xml/manual/abi.xml: Fix grammar.
>        (Symbol versioning on the libstdc++.so binary): Fix mapfile path.
>        (Incremental bumping of a library pre-defined macro): Fix
>        c++config path.
>        (Incremental bumping of a library pre-defined macro,
>        _GLIBCPP_VERSION): Likewise.
>        (Matching each specific C++ compiler release to a specific set of
>        C++ include files): Fix acinclude.m4 path.
>        (Prerequisites): Allow for Sun linker on Solaris 2.5+.
>        Use proper link to Configuring.
>        Fix acinclude.m4 path.
>        (Checking Active): Allow for additional symbol versioning styles.
>        Provide Solaris 2 example with pvs -r.
>        (Bibliography): Update Linker and Libraries Guide, C++ Migration
>        Guide entries.
>        * doc/html/manual/abi.html: Regenerate

Deferring this to libstdc++ maintainers.

Paolo

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Paolo Bonzini <bonzini@gnu.org> writes:

>>        contrib:
>>        * make_sunver.pl: New file.
>
> Not sure this belongs in contrib.  Probably the toplevel or, for now,
> libstdc++-v3, is a better place.

I don't like to clutter toplevel with random helper scripts.  It seems
to fall into the same class as contrib/test_summary, which is used by
make mail-report.log.

Since the same script will be used by all other (already approved or to
be resubmitted) Sun versioning patches, libstdc++-v3 isn't appropriate.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Bonzini]

On 07/01/2010 09:22 AM, Rainer Orth wrote:
> Paolo Bonzini<bonzini@gnu.org>  writes:
>
>>>         contrib:
>>>         * make_sunver.pl: New file.
>>
>> Not sure this belongs in contrib.  Probably the toplevel or, for now,
>> libstdc++-v3, is a better place.
>
> I don't like to clutter toplevel with random helper scripts.  It seems
> to fall into the same class as contrib/test_summary, which is used by
> make mail-report.log.

That's different from something that is run (for determinate targets) on 
a normal "../configure && make".  It seems more similar to "compile", 
"depcomp" or "config-ml.in".  Anyway, contrib be it.

> Since the same script will be used by all other (already approved or to
> be resubmitted) Sun versioning patches, libstdc++-v3 isn't appropriate.

Yes, that's why I wrote "for now".  But if there are already approved 
patches, it's better not to put it there indeed.

Paolo

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Paolo Bonzini <bonzini@gnu.org> writes:

>> I don't like to clutter toplevel with random helper scripts.  It seems
>> to fall into the same class as contrib/test_summary, which is used by
>> make mail-report.log.
>
> That's different from something that is run (for determinate targets) on a
> normal "../configure && make".  It seems more similar to "compile",
> "depcomp" or "config-ml.in".  Anyway, contrib be it.

Ok.  Perhaps it would be helpful to have a new toplevel directory for
stuff like this?   I think aux is what several other projects use.
toplevel is way too crowded right now.

It seems the following files could go there:

compile
config-ml.in
config.guess
config.rpath
config.sub
depcomp
install-sh
libtool-ldflags
libtool.m4
ltgcc.m4
ltmain.sh
ltoptions.m4
ltsugar.m4
ltversion.m4
lt~obsolete.m4
missing
mkdep
mkinstalldirs
move-if-change
symlink-tree
ylwrap

Perhaps start with aux now for make_sunver.pl and move the rest there in
a subsequent patch?  On the other hand, this would have to be
coordinated with src, so seems like a considerable effort.

>> Since the same script will be used by all other (already approved or to
>> be resubmitted) Sun versioning patches, libstdc++-v3 isn't appropriate.
>
> Yes, that's why I wrote "for now".  But if there are already approved
> patches, it's better not to put it there indeed.

The libgfortran and libssp patches have been approved.  I'll have to
re-submit the libgomp patch and post the libjava one for the first time.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Paolo Bonzini <bonzini@gnu.org> writes:

>> Ok.  Perhaps it would be helpful to have a new toplevel directory for
>> stuff like this?   I think aux is what several other projects use.
>
> build-aux usually.  But I won't have time to do that, so unless there's
> a volunteer I doubt it's a good idea to start a new directory for a single
> file.

Ok, incomplete transitions and such :-)  I may give it a try when I've
got some spare time.

> Pick your poison between toplevel and contrib. :)

I'll keep it in contrib for now, so there's no need to re-test.

> libtool m4 files should go in config (this is not so simple
> unfortunately because it will cause some projects to pick
> up config/override.m4 even though they're not using it
> yet; newlib especially).  Everything else is indeed good
> for build-aux.

I will keep that in mind if/when I get to this.

I don't think I need approval for the actual make_sunver.pl file, since
it's only used on Solaris.  So unless there are comments, I'll wait for
libstdc++-v3 approval.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Bonzini]

On Thu, Jul 1, 2010 at 10:07, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> Paolo Bonzini <bonzini@gnu.org> writes:
>
>>> I don't like to clutter toplevel with random helper scripts.  It seems
>>> to fall into the same class as contrib/test_summary, which is used by
>>> make mail-report.log.
>>
>> That's different from something that is run (for determinate targets) on a
>> normal "../configure && make".  It seems more similar to "compile",
>> "depcomp" or "config-ml.in".  Anyway, contrib be it.
>
> Ok.  Perhaps it would be helpful to have a new toplevel directory for
> stuff like this?   I think aux is what several other projects use.

build-aux usually.  But I won't have time to do that, so unless there's
a volunteer I doubt it's a good idea to start a new directory for a single
file.

Pick your poison between toplevel and contrib. :)

> compile
> config-ml.in
> config.guess
> config.rpath
> config.sub
> depcomp
> install-sh
> libtool-ldflags
> libtool.m4
> ltgcc.m4
> ltmain.sh
> ltoptions.m4
> ltsugar.m4
> ltversion.m4
> lt~obsolete.m4
> missing
> mkdep
> mkinstalldirs
> move-if-change
> symlink-tree
> ylwrap

libtool m4 files should go in config (this is not so simple
unfortunately because it will cause some projects to pick
up config/override.m4 even though they're not using it
yet; newlib especially).  Everything else is indeed good
for build-aux.

Paolo

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Carlini]

Hi Rainer,
> Ok for mainline?
>   
I didn't study the v3 bits in any detail, but it looks good to me, and
consistent with the plans. Can you confirm that for non-solaris targets
no changes whatsoever are expected?

I say, please wait one more day to be safe, and then the v3 bits are
approved to go in.

Thanks!
Paolo.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Hi Paolo,

> I didn't study the v3 bits in any detail, but it looks good to me, and
> consistent with the plans. Can you confirm that for non-solaris targets
> no changes whatsoever are expected?

right: the patch only adds a new versioning type (sun), to be used only
on Solaris 2 with Sun ld, and disables GNU-style symbol renaming on
Solaris even with GNU ld.  This is done via comments in the version maps
that look like cpp conditionals and are only processed by an sed
one-liner when generating the version map.  Additionaly, a couple of
.symver directives are disabled, controlled by the same conditional, to
make sure the versions stay the same with Sun ld and GNU ld.

> I say, please wait one more day to be safe, and then the v3 bits are
> approved to go in.

Great, thanks.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Bonzini]

On 07/01/2010 12:19 PM, Rainer Orth wrote:
>> please wait one more day to be safe, and then the v3 bits are
>> approved to go in.
>
> Great, thanks.

Trunk is frozen in fact, so please wait for the end of the freeze, too.

(BTW, a better precedent for contrib/ is contrib/compare-debug.  So 
contrib is definitely a more than decent choice).

Paolo

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Carlini]

On 07/01/2010 12:26 PM, Paolo Bonzini wrote:
> On 07/01/2010 12:19 PM, Rainer Orth wrote:
>>> please wait one more day to be safe, and then the v3 bits are
>>> approved to go in.
>>
>> Great, thanks.
> Trunk is frozen in fact, so please wait for the end of the freeze, too.
For sure. Don't make the same mistake I did yesterday evening ;)

Paolo.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Paolo Bonzini <bonzini@gnu.org> writes:

> Trunk is frozen in fact, so please wait for the end of the freeze, too.

Sure.  I'll submit the libgomp patch soon and probably commit the whole
bunch (as separate check-ins) after everything is approved.

> (BTW, a better precedent for contrib/ is contrib/compare-debug.  So contrib
> is definitely a more than decent choice).

Ok, fine.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Mike Stump]

On Jul 1, 2010, at 1:07 AM, Rainer Orth wrote:
> Perhaps it would be helpful to have a new toplevel directory for
> stuff like this?

The way I think of contrib, is for stuff other than things used by make && make check && make install.  Free from the possibility to break the build, the rules for contrib can be more relaxed.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Paolo Carlini <paolo.carlini@oracle.com> writes:

> I say, please wait one more day to be safe, and then the v3 bits are
> approved to go in.

Installed now.  Unfortunately, I haven't managed to regenerate
doc/html/manual/abi.html and doc/html/manual/configure.html, so I've
omitted them.

Could someone who's better versed in the magic incantations of XML tools
do that for me?

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Carlini]

Hi,
> Paolo Carlini <paolo.carlini@oracle.com> writes:
>
>   
>> I say, please wait one more day to be safe, and then the v3 bits are
>> approved to go in.
>>     
> Installed now.  

Rainer, are you *sure* that HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
is actually defined somewhere on, eg, linux, for use in gnu.ver etc?
Because I did a quick build on x86_64-linux and inside the libstdc++-v3
build dir I only see
_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT defined, in
config.h + _GLIBCXX__GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
in c++config.h. Something seems fishy...
> Unfortunately, I haven't managed to regenerate
> doc/html/manual/abi.html and doc/html/manual/configure.html, so I've
> omitted them.
>
> Could someone who's better versed in the magic incantations of XML tools
> do that for me?
>   
Jon, can you help with this?

Thanks,
Paolo.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Carlini]

On 07/02/2010 12:34 PM, Paolo Carlini wrote:
> Hi,
>   
>> Paolo Carlini <paolo.carlini@oracle.com> writes:
>>
>>   
>>     
>>> I say, please wait one more day to be safe, and then the v3 bits are
>>> approved to go in.
>>>     
>>>       
>> Installed now.  
>>     
> Rainer, are you *sure* that HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
> is actually defined somewhere on, eg, linux, for use in gnu.ver etc?
> Because I did a quick build on x86_64-linux and inside the libstdc++-v3
> build dir I only see
> _GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT defined, in
> config.h + _GLIBCXX__GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
> in c++config.h. Something seems fishy...
>   
And abi_check fails. Something is badly wrong on linux. Of course always
test on linux too when testing this kind of change!!!! Please fix
quickly or revert, thanks.

Paolo.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Paolo Carlini <paolo.carlini@oracle.com> writes:

>> Rainer, are you *sure* that HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
>> is actually defined somewhere on, eg, linux, for use in gnu.ver etc?
>> Because I did a quick build on x86_64-linux and inside the libstdc++-v3
>> build dir I only see
>> _GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT defined, in
>> config.h + _GLIBCXX__GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
>> in c++config.h. Something seems fishy...
>>   
> And abi_check fails. Something is badly wrong on linux. Of course always
> test on linux too when testing this kind of change!!!! Please fix
> quickly or revert, thanks.

I think I see now what's going on.  The following patch should fix it:

* There was a syntax error in acinclude.m4: a missing ;; in the default
  case.

* I AC_DEFINE'd the _GLIBCXX_-prefixed symbol in acinclude.m4, while the
  files under src include c++config.h which adds another level of
  prefixing.

Could you please test this for me?  I don't have ready access to
GNU/Linux.

Sorry for the mess.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


2010-07-02  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* acinclude.m4 (symvers_renaming): Define
	HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT instead of
	_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT.
	Fix syntax error.
	* config.h.in: Regenerate.
	* configure: Regenerate.

diff -r 08cc828c8afb libstdc++-v3/acinclude.m4
--- a/libstdc++-v3/acinclude.m4	Mon Jun 28 16:33:40 2010 +0200
+++ b/libstdc++-v3/acinclude.m4	Fri Jul 02 13:43:56 2010 +0200
@@ -2998,9 +2998,9 @@
        symvers_renaming=no  ;;
      # Other platforms with GNU symbol versioning (GNU/Linux, more?) do.
      *)
-       AC_DEFINE(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT, 1,
+       AC_DEFINE(HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT, 1,
          [Define to 1 if the target runtime linker supports binding the same symbol to different versions.])
-       symvers_renaming=yes
+       symvers_renaming=yes  ;;
     esac
 fi
 GLIBCXX_CONDITIONAL(ENABLE_SYMVERS_SOL2, test $symvers_renaming = no)

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

I've just got a bootstrap fail on  i686-apple-darwin9 with :

make[3]: *** No rule to make target `/GCC/gcc-live-trunk/libssp/../ 
contrib/make_sunver.pl', needed by `ssp.map-sun'.  Stop.

same issue... or different?
cheers,
Iain


On 2 Jul 2010, at 12:46, Rainer Orth wrote:

> Paolo Carlini <paolo.carlini@oracle.com> writes:
>
>>> Rainer, are you *sure* that  
>>> HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
>>> is actually defined somewhere on, eg, linux, for use in gnu.ver etc?
>>> Because I did a quick build on x86_64-linux and inside the libstdc+ 
>>> +-v3
>>> build dir I only see
>>> _GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT defined, in
>>> config.h +  
>>> _GLIBCXX__GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
>>> in c++config.h. Something seems fishy...
>>>
>> And abi_check fails. Something is badly wrong on linux. Of course  
>> always
>> test on linux too when testing this kind of change!!!! Please fix
>> quickly or revert, thanks.
>
> I think I see now what's going on.  The following patch should fix it:
>
> * There was a syntax error in acinclude.m4: a missing ;; in the  
> default
>  case.
>
> * I AC_DEFINE'd the _GLIBCXX_-prefixed symbol in acinclude.m4, while  
> the
>  files under src include c++config.h which adds another level of
>  prefixing.
>
> Could you please test this for me?  I don't have ready access to
> GNU/Linux.
>
> Sorry for the mess.
>
> 	Rainer
>
> -- 
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2010-07-02  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
>
> 	* acinclude.m4 (symvers_renaming): Define
> 	HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT instead of
> 	_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT.
> 	Fix syntax error.
> 	* config.h.in: Regenerate.
> 	* configure: Regenerate.
>
> diff -r 08cc828c8afb libstdc++-v3/acinclude.m4
> --- a/libstdc++-v3/acinclude.m4	Mon Jun 28 16:33:40 2010 +0200
> +++ b/libstdc++-v3/acinclude.m4	Fri Jul 02 13:43:56 2010 +0200
> @@ -2998,9 +2998,9 @@
>        symvers_renaming=no  ;;
>      # Other platforms with GNU symbol versioning (GNU/Linux, more?)  
> do.
>      *)
> -        
> AC_DEFINE(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT, 1,
> +       AC_DEFINE(HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT, 1,
>          [Define to 1 if the target runtime linker supports binding  
> the same symbol to different versions.])
> -       symvers_renaming=yes
> +       symvers_renaming=yes  ;;
>     esac
> fi
> GLIBCXX_CONDITIONAL(ENABLE_SYMVERS_SOL2, test $symvers_renaming = no)

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Carlini]

Hi,
> I think I see now what's going on. The following patch should fix it:
> * There was a syntax error in acinclude.m4: a missing ;; in the default
>   case.
>
> * I AC_DEFINE'd the _GLIBCXX_-prefixed symbol in acinclude.m4, while the
>   files under src include c++config.h which adds another level of
>   prefixing.
>
> Could you please test this for me?  I don't have ready access to
> GNU/Linux.
>   
The patch apparently works, I'm finishing regtesting it but abi_check is
back to normality.
> Sorry for the mess.
>   
No problem, your contribution is certainly welcome, but please, in the
future, make sure to *somehow* test on linux too, where versioning s vital.

Thanks,
Paolo.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Carlini]

On 07/02/2010 02:03 PM, IainS wrote:
> I've just got a bootstrap fail on  i686-apple-darwin9 with :
>
> make[3]: *** No rule to make target
> `/GCC/gcc-live-trunk/libssp/../contrib/make_sunver.pl', needed by
> `ssp.map-sun'.  Stop.
>
> same issue... or different?
Different, I would say: evidently you are simply missing make_sunver.pl,
which you can easily get with an svn update.

Paolo.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

On 2 Jul 2010, at 13:08, Paolo Carlini wrote:

> On 07/02/2010 02:03 PM, IainS wrote:
>> I've just got a bootstrap fail on  i686-apple-darwin9 with :
>>
>> make[3]: *** No rule to make target
>> `/GCC/gcc-live-trunk/libssp/../contrib/make_sunver.pl', needed by
>> `ssp.map-sun'.  Stop.
>>
>> same issue... or different?
> Different, I would say: evidently you are simply missing  
> make_sunver.pl,
> which you can easily get with an svn update.

Ah, I see just a fluke ... I happened to hit the revision between your  
commits.
Will re-try the bootstrap.
cheers,
Iain

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Hi Paolo,

>> Could you please test this for me?  I don't have ready access to
>> GNU/Linux.
>>   
> The patch apparently works, I'm finishing regtesting it but abi_check is
> back to normality.

let me know when you're done and I'll commit it.

>> Sorry for the mess.
>>   
> No problem, your contribution is certainly welcome, but please, in the
> future, make sure to *somehow* test on linux too, where versioning s vital.

Ok, I'll see what I can do with either VirtualBox or the test farm.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Paolo Carlini <paolo.carlini@oracle.com> writes:

> On 07/02/2010 02:03 PM, IainS wrote:
>> I've just got a bootstrap fail on  i686-apple-darwin9 with :
>>
>> make[3]: *** No rule to make target
>> `/GCC/gcc-live-trunk/libssp/../contrib/make_sunver.pl', needed by
>> `ssp.map-sun'.  Stop.
>>
>> same issue... or different?
> Different, I would say: evidently you are simply missing make_sunver.pl,
> which you can easily get with an svn update.

The file should have been committed with the libstdc++ sunver patch,
which went in before the libssp one, but somehow escaped me.  I've
comitted as soon as I noticed.

On the other hand, that script should only be used if
LIBSSP_USE_SYMVER_SUN, which has no business being defined on Darwin.

Could you please check the configure output for `whether symbol
versioning is supported'?  It should be no on Darwin.  Otherwise, please
have a look at libssp/config.log to see what's going on there.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

On 2 Jul 2010, at 13:22, Rainer Orth wrote:

> Paolo Carlini <paolo.carlini@oracle.com> writes:
>
>> On 07/02/2010 02:03 PM, IainS wrote:
>>> I've just got a bootstrap fail on  i686-apple-darwin9 with :
>>>
>>> make[3]: *** No rule to make target
>>> `/GCC/gcc-live-trunk/libssp/../contrib/make_sunver.pl', needed by
>>> `ssp.map-sun'.  Stop.
>>>
>>> same issue... or different?
>> Different, I would say: evidently you are simply missing  
>> make_sunver.pl,
>> which you can easily get with an svn update.
>
> The file should have been committed with the libstdc++ sunver patch,
> which went in before the libssp one, but somehow escaped me.  I've
> comitted as soon as I noticed.
>
> On the other hand, that script should only be used if
> LIBSSP_USE_SYMVER_SUN, which has no business being defined on Darwin.

indeed .

> Could you please check the configure output for `whether symbol
> versioning is supported'?  It should be no on Darwin.  Otherwise,  
> please
> have a look at libssp/config.log to see what's going on there.

bootstrap is running with 161706, do I need to apply the patch at:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html
?

cheers,
Iain

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

IainS <developer@sandoe-acoustics.co.uk> writes:

>> On the other hand, that script should only be used if
>> LIBSSP_USE_SYMVER_SUN, which has no business being defined on Darwin.
>
> indeed .

That's bad.  I suppose the Darwin ld either silently accepts/ignores -M
or it has a different meaning there which happens to have no ill effect.

>> Could you please check the configure output for `whether symbol
>> versioning is supported'?  It should be no on Darwin.  Otherwise, please
>> have a look at libssp/config.log to see what's going on there.
>
> bootstrap is running with 161706, do I need to apply the patch at:
> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html

Shouldn't be necessary since Darwin has no GNU-style symbol versioning,
AFAIK.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Paolo Carlini]

On 07/02/2010 02:29 PM, Rainer Orth wrote:
>> bootstrap is running with 161706, do I need to apply the patch at:
>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html
>>     
The patch is already in.
> Shouldn't be necessary since Darwin has no GNU-style symbol versioning,
> AFAIK.
>   
But note that lately Darwin has some sort of versioning, I don't know
the details. I think we should be careful here, and make sure we really
enable the new machinery on *solaris and solaris only* in a very direct
and active way.

Paolo.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

On 2 Jul 2010, at 13:29, Rainer Orth wrote:

> IainS <developer@sandoe-acoustics.co.uk> writes:
>
>>> On the other hand, that script should only be used if
>>> LIBSSP_USE_SYMVER_SUN, which has no business being defined on  
>>> Darwin.
>>
>> indeed .
>
> That's bad.  I suppose the Darwin ld either silently accepts/ignores  
> -M
> or it has a different meaning there which happens to have no ill  
> effect.

hm darwin more usually  barfs on things - unless they are BSD  
compatibility flags...

I don't know exactly what you're trying to achieve...
... Darwin has it's own library versioning system, but not symbol  
versioning, per se
[I guess it could be achieved with two-level namespaces, but I don't  
think anyone is proposing to add that to darwin's gcc port at the  
moment].

the manual pages for Darwin ld:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/ld.1.html

>>> Could you please check the configure output for `whether symbol
>>> versioning is supported'?  It should be no on Darwin.  Otherwise,  
>>> please
>>> have a look at libssp/config.log to see what's going on there.
>>
>> bootstrap is running with 161706, do I need to apply the patch at:
>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html
>
> Shouldn't be necessary since Darwin has no GNU-style symbol  
> versioning,
> AFAIK.

OK.   I'll let you know how it goes :)
Iain

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Paolo Carlini <paolo.carlini@oracle.com> writes:

> On 07/02/2010 02:29 PM, Rainer Orth wrote:
>>> bootstrap is running with 161706, do I need to apply the patch at:
>>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html
>>>     
> The patch is already in.

Ok, thanks.

>> Shouldn't be necessary since Darwin has no GNU-style symbol versioning,
>> AFAIK.
>>   
> But note that lately Darwin has some sort of versioning, I don't know
> the details. I think we should be careful here, and make sure we really
> enable the new machinery on *solaris and solaris only* in a very direct
> and active way.

Indeed, though AFAICS only in libstdc++.  I have been extra careful to
enable Sun symbol versioning only for Solaris in libstdc++:

@@ -2834,6 +2837,20 @@
       case ${target_os} in
         darwin*)
 	  enable_symvers=darwin ;;
+	# Sun symbol versioning exists since Solaris 2.5.
+	solaris2.[[5-9]]* | solaris2.1[[0-9]]*)
+	  # make_sunver.pl needs GNU c++filt to support extern "C++" in
+	  # version scripts, so disable symbol versioning if none can be
+	  # found.
+	  if test -z "$ac_cv_path_CXXFILT"; then
+	    AC_MSG_WARN([=== You have requested Sun symbol versioning, but])
+	    AC_MSG_WARN([=== no GNU c++filt could  be found.])
+	    AC_MSG_WARN([=== Symbol versioning will be disabled.])
+	    enable_symvers=no
+	  else
+	    enable_symvers=sun
+	  fi
+	  ;;
         *)
           enable_symvers=no ;;
       esac

On the other hand, in libssp I simply check if

$ gcc -fPIC -shared -Wl,-M,./conftest.map

works.  It seems that it appears to do so on Darwin, though either with
no or with a different effect than expected.

That's the current mess with the different symbol versioning checks in
libstdc++-v3, libgomp, libgfortran, libssp, and libjava.

I meant to fix this and posted about the problem back in February

	http://gcc.gnu.org/ml/gcc/2010-02/msg00342.html

but that message met with deafening silence ;-(  I still plan to unify
this somehow, at least for GCC, but wanted to get something in for 4.6.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

IainS <developer@sandoe-acoustics.co.uk> writes:

>> That's bad.  I suppose the Darwin ld either silently accepts/ignores -M
>> or it has a different meaning there which happens to have no ill effect.
>
> hm darwin more usually  barfs on things - unless they are BSD compatibility
> flags...

This may be the 4.3BSD -M option to produce a load map, but that doesn't
take an option argument and isn't listed on the ld(1) man page you cite.

> I don't know exactly what you're trying to achieve...
> ... Darwin has it's own library versioning system, but not symbol
> versioning, per se

This is not about library versioning at all, but for libstdc++.so only,
there's already libstdc++-v3/scripts/make_exports.pl for Darwin (in
fact, that script is the parent of make_sunver.pl) that creates an
export list, this way at least hiding all global symbols that are not
supposed to be exported.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

On 2 Jul 2010, at 13:39, IainS wrote:

>>>> Could you please check the configure output for `whether symbol
>>>> versioning is supported'?  It should be no on Darwin.  Otherwise,  
>>>> please
>>>> have a look at libssp/config.log to see what's going on there.
>>>
>>> bootstrap is running with 161706, do I need to apply the patch at:
>>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00131.html
>>
>> Shouldn't be necessary since Darwin has no GNU-style symbol  
>> versioning,
>> AFAIK.
>
> OK.   I'll let you know how it goes :)

hm, not good:
chk.o \
          `echo  | \
             sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \
          > ssp.map-sun || (rm -f ssp.map-sun ; exit 1)
nm: no name list
unknown nm output ___guard_setup t 110 0 at /GCC/gcc-live-trunk/ 
libssp/../contrib/make_sunver.pl line 69, <NM> line 4.
make[2]: *** [ssp.map-sun] Error 1

===

I look in libssp at config.log [m32 and m64] and see:

configure:4126: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6- 
trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/ 
GCC/gcc-4-
6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6-install/i686- 
apple-darwin9/include -isystem /GCC/gcc-4-6-install/i686-apple-darwin9/ 
sys-in
clude    -o conftest -g -O2   -fPIC -shared -Wl,--version-script,./ 
conftest.map conftest.c  >&5
ld: unknown option: --version-script
collect2: ld returned 1 exit status
configure:4126: $? = 1

but no other references to "symbol" that have any bearing..
so perhaps the test is not being run at all for Darwin?

Iain

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

IainS <developer@sandoe-acoustics.co.uk> writes:

> hm, not good:
> chk.o \
>          `echo  | \
>             sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \
>          > ssp.map-sun || (rm -f ssp.map-sun ; exit 1)
> nm: no name list
> unknown nm output ___guard_setup t 110 0 at /GCC/gcc-live-trunk/
> libssp/../contrib/make_sunver.pl line 69, <NM> line 4.
> make[2]: *** [ssp.map-sun] Error 1

but sort of expected: this has no business being run on anything but Solaris.

> I look in libssp at config.log [m32 and m64] and see:
>
> configure:4126: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6-
> trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/
> GCC/gcc-4-
> 6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6-install/i686-
> apple-darwin9/include -isystem /GCC/gcc-4-6-install/i686-apple-darwin9/
> sys-in
> clude    -o conftest -g -O2   -fPIC -shared -Wl,--version-script,./
> conftest.map conftest.c  >&5
> ld: unknown option: --version-script
> collect2: ld returned 1 exit status
> configure:4126: $? = 1

This is the first test for GNU ld --version-script, which obviously
fails.

> but no other references to "symbol" that have any bearing..
> so perhaps the test is not being run at all for Darwin?

Sure it is, otherwise you wouldn't see Sun-style symbol versioning being
enabled.  The next test with

gcc -fPIC -shared -Wl,-M,./conftest.map

is the interesting one.  What happens there?  And please provide the
relevant output fragment of the libssp configure run, too.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

On 2 Jul 2010, at 13:51, Rainer Orth wrote:

> IainS <developer@sandoe-acoustics.co.uk> writes:
>
>>> That's bad.  I suppose the Darwin ld either silently accepts/ 
>>> ignores -M
>>> or it has a different meaning there which happens to have no ill  
>>> effect.
>>
>> hm darwin more usually  barfs on things - unless they are BSD  
>> compatibility
>> flags...
>
> This may be the 4.3BSD -M option to produce a load map, but that  
> doesn't
> take an option argument and isn't listed on the ld(1) man page you  
> cite.

let me know what you want to test - and I'll give it a whirl..

>> I don't know exactly what you're trying to achieve...
>> ... Darwin has it's own library versioning system, but not symbol
>> versioning, per se
>
> This is not about library versioning at all, but for libstdc++.so  
> only,
> there's already libstdc++-v3/scripts/make_exports.pl for Darwin (in
> fact, that script is the parent of make_sunver.pl) that creates an
> export list, this way at least hiding all global symbols that are not
> supposed to be exported.

Ah yes, I remember looking at that ..
.. it would be good to update it to deal with Darwin's _eh situation
(removing the _eh exports, which should not be coalescable AFAICS ,at  
least for darwin >= 9).

(I also suspect that there are some wrong visibilities too - from some  
testing I did with the static-libstdc++ ... but I've not looked at it  
in several months).

time, as ever, is the short commodity.

Iain.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

On 2 Jul 2010, at 13:58, Rainer Orth wrote:

>> but no other references to "symbol" that have any bearing..
>> so perhaps the test is not being run at all for Darwin?
>
> Sure it is, otherwise you wouldn't see Sun-style symbol versioning  
> being
> enabled.  The next test with
>
> gcc -fPIC -shared -Wl,-M,./conftest.map
>
> is the interesting one.  What happens there?  And please provide the
> relevant output fragment of the libssp configure run, too.

configure:4156: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6- 
trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/ 
GCC/gcc-4-6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6- 
install/i686-apple-darwin9/include -isystem /GCC/gcc-4-6-install/i686- 
apple-darwin9/sys-include    -o conftest -g -O2   -fPIC -shared -Wl,- 
M,./conftest.map conftest.c  >&5
ld warning: in ./conftest.map, file is not of required architecture
configure:4156: $? = 0
configure:4166: result: sun

hm.  I guess that -M is unrecognized and the linker falls back to it's  
default which is to expect the remaining items to be objects - which,  
of course, the ma file is not.  However, since the link does not  
actually fail - I guess it only reports a warning.

Iain.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

On 2 Jul 2010, at 14:20, IainS wrote:

>
> On 2 Jul 2010, at 13:58, Rainer Orth wrote:
>
>>> but no other references to "symbol" that have any bearing..
>>> so perhaps the test is not being run at all for Darwin?
>>
>> Sure it is, otherwise you wouldn't see Sun-style symbol versioning  
>> being
>> enabled.  The next test with
>>
>> gcc -fPIC -shared -Wl,-M,./conftest.map
>>
>> is the interesting one.  What happens there?  And please provide the
>> relevant output fragment of the libssp configure run, too.
>
> configure:4156: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6- 
> trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/ 
> GCC/gcc-4-6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6- 
> install/i686-apple-darwin9/include -isystem /GCC/gcc-4-6-install/ 
> i686-apple-darwin9/sys-include    -o conftest -g -O2   -fPIC -shared  
> -Wl,-M,./conftest.map conftest.c  >&5
> ld warning: in ./conftest.map, file is not of required architecture
> configure:4156: $? = 0
> configure:4166: result: sun
>
> hm.  I guess that -M is unrecognized and the linker falls back to  
> it's default which is to expect the remaining items to be objects -  
> which, of course, the ma file is not.  However, since the link does  
> not actually fail - I guess it only reports a warning

As an aside, I wonder if the autoconfigury/libtool people have already  
resolved all these issues?
Iain

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

On 2 Jul 2010, at 14:20, IainS wrote:

> On 2 Jul 2010, at 13:58, Rainer Orth wrote:
>
>>> but no other references to "symbol" that have any bearing..
>>> so perhaps the test is not being run at all for Darwin?
>>
>> Sure it is, otherwise you wouldn't see Sun-style symbol versioning  
>> being
>> enabled.  The next test with
>>
>> gcc -fPIC -shared -Wl,-M,./conftest.map
>>
>> is the interesting one.  What happens there?  And please provide the
>> relevant output fragment of the libssp configure run, too.
>
> configure:4156: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6- 
> trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/ 
> GCC/gcc-4-6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6- 
> install/i686-apple-darwin9/include -isystem /GCC/gcc-4-6-install/ 
> i686-apple-darwin9/sys-include    -o conftest -g -O2   -fPIC -shared  
> -Wl,-M,./conftest.map conftest.c  >&5
> ld warning: in ./conftest.map, file is not of required architecture
> configure:4156: $? = 0
> configure:4166: result: sun
>
> hm.  I guess that -M is unrecognized and the linker falls back to  
> it's default which is to expect the remaining items to be objects -  
> which, of course, the ma file is not.  However, since the link does  
> not actually fail - I guess it only reports a warning.

from ld (tools version 2.5) manual page linked earlier:
-M (32-bit only) Produce a load map, listing all the segments and  
sections. The list includes the address where each input file's  
section appears in the output file, as well as the section's size.  
This option overlaps with a compiler option. If you use the compiler  
driver cc(1) to invoke ld, invoke this option in this way: -Wl,-M.
so, although it's not listed in the 3.2.x tools, I imagine that it is  
silently ignored for backward-compatibility.

Iain.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

IainS <developer@sandoe-acoustics.co.uk> writes:

> configure:4156: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6-
> trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/
> GCC/gcc-4-6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6-
> install/i686-apple-darwin9/include -isystem /GCC/gcc-4-6-install/i686-
> apple-darwin9/sys-include    -o conftest -g -O2   -fPIC -shared -Wl,-
> M,./conftest.map conftest.c  >&5
> ld warning: in ./conftest.map, file is not of required architecture
> configure:4156: $? = 0
> configure:4166: result: sun
>
> hm.  I guess that -M is unrecognized and the linker falls back to it's
> default which is to expect the remaining items to be objects - which,  of
> course, the ma file is not.  However, since the link does not  actually
> fail - I guess it only reports a warning.

I've seen similar behavior in the SGI ld which warns about an unknown
option, but still exits with 0.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

IainS <developer@sandoe-acoustics.co.uk> writes:

> As an aside, I wonder if the autoconfigury/libtool people have already
> resolved all these issues?

They have, but only halfheartedly: they provide AC_LANG_WERROR, but no
way to turn that flag off again.  That's what I used to work around the
libjava testsuite failures on IRIX 6.5:

	http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01889.html

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

IainS <developer@sandoe-acoustics.co.uk> writes:

> from ld (tools version 2.5) manual page linked earlier:
> -M (32-bit only) Produce a load map, listing all the segments and
> sections. The list includes the address where each input file's  section
> appears in the output file, as well as the section's size.  This option
> overlaps with a compiler option. If you use the compiler  driver cc(1) to
> invoke ld, invoke this option in this way: -Wl,-M.
> so, although it's not listed in the 3.2.x tools, I imagine that it is
> silently ignored for backward-compatibility.

That's what I feared.  At first, I was tempted to use the same hack as
in the libjava configure.ac, but since the check for Sun style symbol
versioning makes sense only on Solaris, I'd go for the following
instead.

Could you please give it a try on Darwin?

If it works for you, I'll commit as obvious.

Thanks.
	Rainer


2010-07-02  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	libssp:
	* configure.ac (ssp_use_symver): Only check for Sun-style symbol
	versioning on Solaris 2.
	* configure: Regenerate.

diff -r 08cc828c8afb libssp/configure.ac
--- a/libssp/configure.ac	Mon Jun 28 16:33:40 2010 +0200
+++ b/libssp/configure.ac	Fri Jul 02 17:23:54 2010 +0200
@@ -86,15 +86,19 @@
 EOF
   AC_TRY_LINK([int foo;],[],[ssp_use_symver=gnu],[ssp_use_symver=no])
   if test x$ssp_use_symver = xno; then
-    LDFLAGS="$save_LDFLAGS"
-    LDFLAGS="$LDFLAGS -fPIC -shared -Wl,-M,./conftest.map"
-    # Sun ld cannot handle wildcards and treats all entries as undefined.
-    cat > conftest.map <<EOF
+    case "$target_os" in
+      solaris2*)
+        LDFLAGS="$save_LDFLAGS"
+        LDFLAGS="$LDFLAGS -fPIC -shared -Wl,-M,./conftest.map"
+        # Sun ld cannot handle wildcards and treats all entries as undefined.
+        cat > conftest.map <<EOF
 FOO_1.0 {
   global: foo; local: *;
 };
 EOF
-    AC_TRY_LINK([int foo;],[],[ssp_use_symver=sun],[ssp_use_symver=no])
+        AC_TRY_LINK([int foo;],[],[ssp_use_symver=sun],[ssp_use_symver=no])
+    	;;
+    esac
   fi
   LDFLAGS="$save_LDFLAGS"
 fi


-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

On 2 Jul 2010, at 16:20, Rainer Orth wrote:

> IainS <developer@sandoe-acoustics.co.uk> writes:
>
>> configure:4156: /GCC/gcc-4-6-trunk-build/./gcc/xgcc -B/GCC/gcc-4-6-
>> trunk-build/./gcc/ -B/GCC/gcc-4-6-install/i686-apple-darwin9/bin/ -B/
>> GCC/gcc-4-6-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-6-
>> install/i686-apple-darwin9/include -isystem /GCC/gcc-4-6-install/ 
>> i686-
>> apple-darwin9/sys-include    -o conftest -g -O2   -fPIC -shared -Wl,-
>> M,./conftest.map conftest.c  >&5
>> ld warning: in ./conftest.map, file is not of required architecture
>> configure:4156: $? = 0
>> configure:4166: result: sun
>>
>> hm.  I guess that -M is unrecognized and the linker falls back to  
>> it's
>> default which is to expect the remaining items to be objects -  
>> which,  of
>> course, the ma file is not.  However, since the link does not   
>> actually
>> fail - I guess it only reports a warning.
>
> I've seen similar behavior in the SGI ld which warns about an unknown
> option, but still exits with 0.

Darwin's ld will exit with an error message and status = 1 for an  
unrecognized option.

In this case, as I indicated in a follow-up mail, the "-M" option is  
valid for toolsets that are current in darwin 8 (still supported by  
gcc, AFAIK) and silently ignored in toolsets for darwin 9 (at least)  
and probably darwin 10.

so, we need a different discriminator.

cheers,
Iain

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[IainS]

On 2 Jul 2010, at 16:24, Rainer Orth wrote:

> IainS <developer@sandoe-acoustics.co.uk> writes:
>
>> from ld (tools version 2.5) manual page linked earlier:
>> -M (32-bit only) Produce a load map, listing all the segments and
>> sections. The list includes the address where each input file's   
>> section
>> appears in the output file, as well as the section's size.  This  
>> option
>> overlaps with a compiler option. If you use the compiler  driver  
>> cc(1) to
>> invoke ld, invoke this option in this way: -Wl,-M.
>> so, although it's not listed in the 3.2.x tools, I imagine that it is
>> silently ignored for backward-compatibility.
>
> That's what I feared.  At first, I was tempted to use the same hack as
> in the libjava configure.ac, but since the check for Sun style symbol
> versioning makes sense only on Solaris, I'd go for the following
> instead.
>
> Could you please give it a try on Darwin?
>
> If it works for you, I'll commit as obvious.

It works for libssp.

I think a similar change is needed for libgfortran (at least) but  
you'd know better than me the scope of the changes.

thanks
Iain.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

IainS <developer@sandoe-acoustics.co.uk> writes:

> yeah - both OK with those patches and autoreconf.
> I'll do a clean bootstrap now - but I think you're fairly safe.,..

Thanks for the confirmation.  Given that I'm leaving for the weekend in
about two hours and will be away from my mail till monday, I'll check in
this patch now to avoid leaving the tree broken at least for Darwin that
long.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Mike Stump]

On Jul 2, 2010, at 9:13 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 
> Given that I'm leaving for the weekend in
> about two hours and will be away from my mail till monday, I'll check in
> this patch now to avoid leaving the tree broken at least for Darwin that
> long.

Thanks.
> 

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Jonathan Wakely]

On 2 July 2010 11:34, Paolo Carlini wrote:
>> Unfortunately, I haven't managed to regenerate
>> doc/html/manual/abi.html and doc/html/manual/configure.html, so I've
>> omitted them.
>>
>> Could someone who's better versed in the magic incantations of XML tools
>> do that for me?

On linux it's just 'make doc-html' but I don't think doc/Makefile
tries very hard to be portable.

> Jon, can you help with this?

Sure, I'll take care of it.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Rainer Orth]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:

> On 2 July 2010 11:34, Paolo Carlini wrote:
>>> Unfortunately, I haven't managed to regenerate
>>> doc/html/manual/abi.html and doc/html/manual/configure.html, so I've
>>> omitted them.
>>>
>>> Could someone who's better versed in the magic incantations of XML tools
>>> do that for me?
>
> On linux it's just 'make doc-html' but I don't think doc/Makefile
> tries very hard to be portable.

I tried this, but for some reason xsltproc couldn't access the DocBook
XML 4.5 DTD.  Instead it just hang with an open connection to
www.oasis-open.org, and I found no way around this ;-(

>> Jon, can you help with this?
>
> Sure, I'll take care of it.

Great, thanks.  I know I even managed to generate PDF from the XML at
some point, but it was a complete nightmare and required extensive
consultation with our former SGML/XML expert to get there.  Give me
TeXinfo over that mess any day :-)

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Jonathan Wakely]

On 2 July 2010 18:08, Rainer Orth wrote:
>> On linux it's just 'make doc-html' but I don't think doc/Makefile
>> tries very hard to be portable.
>
> I tried this, but for some reason xsltproc couldn't access the DocBook
> XML 4.5 DTD.  Instead it just hang with an open connection to
> www.oasis-open.org, and I found no way around this ;-(

Ah, I think I had to install some additional packages to solve that,
so that I had some (docbook/jade/?) stylesheets available on my local
machine.

I'll regen the HTML and check it in. I also need to coordinate with
Gerald to get the copies on the website updated.

Re: [build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2

[Ralf Wildenhues]

Hello Rainer,

* Rainer Orth wrote on Fri, Jul 02, 2010 at 02:43:06PM CEST:
> I meant to fix this and posted about the problem back in February
> 
> 	http://gcc.gnu.org/ml/gcc/2010-02/msg00342.html
> 
> but that message met with deafening silence ;-(  I still plan to unify
> this somehow, at least for GCC, but wanted to get something in for 4.6.

I'm sorry about the silence regarding having this in Libtool, or
unifying somehow.  I think you are right, that would be a good idea.
I also think it can be done later, if that is better for the work
already done.  There is a thread on the libtool list with a related
request, maybe you can offer your opinion there:
<http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2269/focus=10964>

I'm not sure libtool can generally assume perl to be present on end-user
machines.

Wrt. dealing with linkers that ignore switches unknown to them, you
might benefit from the _LT_LINKER_OPTION macro in libtool.m4 which also
takes (differences in) warning output into account when testing.

Hope that helps; I haven't had time to read the rest of this in detail
(still catching up on mail).

Cheers,
Ralf