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 <p...@lysator.liu.se> 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 n...@esperi.org.uk Olaf Lenz ol...@fias.uni-frankfurt.de Olly Betts o...@muscat.co.uk + Ozkan Sezer seze...@gmail.com Pádraig Brady p...@draigbrady.com Patrice Fromy patrice.fr...@u-psud.fr Patrick Welche pr...@newn.cam.ac.uk 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