multilib patch

[Peter O'Gorman]

Not much response last time, here we go again.

Libtool, for compilers other than gcc, does not usually care about the
compiler's internal search paths, and if it does, it is not very likely
to find .la files in there. In the case of gcc, libtool insists on
knowing the compilers internal search paths and adds them to
sys_lib_search_path_spec. This causes issues, some of which are because
of gcc's .la files containing the build directory, but not limited to
that. It is most likely to cause problems when building for a multilib
target.

I am proposing this as a patch. I do not really like it, but it does get
the paths "right" (for some definition of "right"). I would prefer to
remove the requirement that libtool know about the location of gcc's
libstdc++ etc. and just trust gcc to do the right thing, but that should
probably be left for another time.

Ok to apply to branch-1-5 and forward port to HEAD?

Peter
-- 
Peter O'Gorman
http://pogma.com

 2008-01-30  Peter O'Gorman  <address@hidden>
 
        * libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER): If using gcc, check
        the -L flags output by a test link command also to get a more
        accurate value for sys_lib_search_path_spec.

Index: libtool.m4
===================================================================
RCS file: /sources/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.195
diff -u -r1.314.2.195 libtool.m4
--- libtool.m4  30 Jan 2008 06:40:57 -0000      1.314.2.195
+++ libtool.m4  30 Jan 2008 08:04:54 -0000
@@ -1350,7 +1350,68 @@
   sys_lib_search_path_spec=`echo $lt_search_path_spec`
 else
   sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
-fi])
+fi
+# And it gets worse. gcc -print-search-dirs combined with gcc
+# -print-multi-os-directory does not find all the directories that gcc
+# searches. When building gcc -m32 on a system which defaults to 64
+# bit builds, gcc also searches directories like e.g.
+# /usr/lib/gcc/x86_64-redhat-linux/4.1.2/32 but
+# -print-multi-os-directory outputs ../lib. I no longer know why we
+# don't just assume that gcc does the right thing, so we now verbose
+# link something grab the -L paths and prepend to
+# sys_lib_search_path_spec is not already there...
+# Sad yet?
+#
+# We could probably get away without conftest.c and just do 
+# 'gcc -v -x c -o /dev/null /dev/null', but lets be conservative.
+#
+# Need LDFLAGS, but not with -L.
+_lt_ldflags=
+for _ld_flag in "$LDFLAGS"; do
+  case "$_ld_flag" in
+    -L*) ;;
+    *) _lt_ldflags="$_ld_flag $_lt_ldflags" ;;
+  esac
+done 
+echo 'int main() { return 1;}' > conftest.c
+_lt_verbose_search_libs=`$CC $CFLAGS $CPPFLAGS $_lt_ldflags -o conftest -v 
conftest.c 2>&1 | awk '
+BEGIN {lt_space=0;} /-L/ {
+  for (lt_x=1; lt_x <= NF; lt_x++) {
+    if ( substr($lt_x,1,2) == "-L") {
+      lt_y=substr($lt_x,3,length($lt_x) -2);
+      if (lt_space > 0) { print " "; }
+      print lt_y;
+      lt_space++;
+    }
+  }
+}' | awk '
+BEGIN {RS=" "; FS="/|\n";} {
+  lt_foo="";
+  lt_count=0;
+  for (lt_i = NF; lt_i > 0; lt_i--) {
+    if ($lt_i != "" && $lt_i != ".") {
+      if ($lt_i == "..") {
+        lt_count++;
+      } else {
+        if (lt_count == 0) {
+          lt_foo="/" $lt_i lt_foo;
+        } else {
+          lt_count--;
+        }
+      }
+    }
+  }
+  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
+  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
+}'`
+rm -rf conftest*
+for _lt_verbose_search_lib in $_lt_verbose_search_libs; do
+  case " $sys_lib_search_path_spec " in
+   *" "$_lt_verbose_search_lib" "*) ;;
+   *) sys_lib_search_path_spec="$_lt_verbose_search_lib 
$sys_lib_search_path_spec" ;;
+  esac
+done
+])
 need_lib_prefix=unknown
 hardcode_into_libs=no