[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[SCM] GNU Libtool branch, master, updated. v2.4.2-397-g0ebb734
From: |
Peter Rosin |
Subject: |
[SCM] GNU Libtool branch, master, updated. v2.4.2-397-g0ebb734 |
Date: |
Tue, 17 Sep 2013 18:38:02 +0000 |
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Libtool".
The branch, master has been updated
via 0ebb734910bf56186dd0c0e84b1c8be507bad336 (commit)
from 75051fb536aa3a84324f61253765ab0e58e91fa2 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 0ebb734910bf56186dd0c0e84b1c8be507bad336
Author: Peter Rosin <address@hidden>
Date: Tue Sep 17 20:33:12 2013 +0200
libtool: trust -print-search-dirs from recent GCC
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.
-----------------------------------------------------------------------
Summary of changes:
THANKS | 1 +
m4/libtool.m4 | 17 ++++++++++++-----
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/THANKS b/THANKS
index f49e5d9..3c30f61 100644
--- a/THANKS
+++ b/THANKS
@@ -152,6 +152,7 @@
Nix address@hidden
Olaf Lenz address@hidden
Olly Betts address@hidden
+ Ozkan Sezer address@hidden
Pádraig Brady address@hidden
Patrice Fromy address@hidden
Patrick Welche address@hidden
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4418a1c..80d7e44 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -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
hooks/post-receive
--
GNU Libtool
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [SCM] GNU Libtool branch, master, updated. v2.4.2-397-g0ebb734,
Peter Rosin <=