]> git.ipfire.org Git - thirdparty/libtool.git/commitdiff
libtool: trust -print-search-dirs from recent GCC
authorPeter Rosin <peda@lysator.liu.se>
Tue, 17 Sep 2013 18:33:12 +0000 (20:33 +0200)
committerPeter Rosin <peda@lysator.liu.se>
Tue, 17 Sep 2013 18:34:29 +0000 (20:34 +0200)
Alan Modra hints in [1] that -print-search-dirs was fixed in
GCC 4.2(?), so that it nowadays automatically appends
-print-multi-os-directory for the applicable directories. I.e.
it should no longer be necessary for libtool to append a second
../lib64 when GCC has already done so. Also, the multi-os
appending loop seems to have been added specifically for early
(arguably broken) bi-arch enabled GCCs that printed -m32
directories even though -m64 was the default [2]. So, my
conclusion is that we want any libtool magic to affect
-print-search-dirs output from contemporary GCCs as little as
possible, while continuing to append the
-print-multi-os-directory for the legacy case.

Fixes bug#15321 reported by Ozkan Sezer.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[2] http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html

* m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER): If any of the
directories printed by -print-search-dirs ends with the
content of -print-multi-os-directory, then assume that
GCC adds the multi-os-directory where appropriate all by
itself and hence don't try to second guess when to add
it manually.
* THANKS: Update.

THANKS
m4/libtool.m4

diff --git a/THANKS b/THANKS
index f49e5d9d1a8b84af577390aa18e46593fb04c9b0..3c30f6120a02f2e569814da62f7c0c828c279af9 100644 (file)
--- a/THANKS
+++ b/THANKS
   Nix                          nix@esperi.org.uk
   Olaf Lenz                    olenz@fias.uni-frankfurt.de
   Olly Betts                   olly@muscat.co.uk
+  Ozkan Sezer                  sezeroz@gmail.com
   Pádraig Brady                       P@draigBrady.com
   Patrice Fromy                        patrice.fromy@u-psud.fr
   Patrick Welche               prlw1@newn.cam.ac.uk
index 4418a1c3ab9f7211e66b84f960dfcab55655e693..80d7e4433a68ba2bb7ece45b76c4e9a6574495ff 100644 (file)
@@ -2233,13 +2233,20 @@ if test yes = "$GCC"; then
     ;;
   esac
   # Ok, now we have the path, separated by spaces, we can step through it
-  # and add multilib dir if necessary.
+  # and add multilib dir if necessary...
   lt_tmp_lt_search_path_spec=
-  lt_multi_os_dir=`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
+  lt_multi_os_dir=/`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
+  # ...but if some path component already ends with the multilib dir we assume
+  # that all is fine and trust -print-search-dirs as is (GCC 4.2? or newer).
+  case "$lt_multi_os_dir; $lt_search_path_spec " in
+  "/; "* | "/.; "* | "/./; "* | *"$lt_multi_os_dir "* | *"$lt_multi_os_dir/ "*)
+    lt_multi_os_dir=
+    ;;
+  esac
   for lt_sys_path in $lt_search_path_spec; do
-    if test -d "$lt_sys_path/$lt_multi_os_dir"; then
-      lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/$lt_multi_os_dir"
-    else
+    if test -d "$lt_sys_path$lt_multi_os_dir"; then
+      lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path$lt_multi_os_dir"
+    elif test -n "$lt_multi_os_dir"; then
       test -d "$lt_sys_path" && \
        lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path"
     fi