On 2013-09-10 16:10, Peter Rosin wrote: > On 2013-09-10 15:56, Ozkan Sezer wrote: >> OK then, I'll keep an eye on mails from this list. >> >> (On an irrelevant note, the archive pages at >> http://lists.gnu.org/archive/html/libtool/2013-09/index.html >> http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html >> doesn't list any mails from me, but the ones from you from this thread >> are there, so I don't know whether any of the mails I send arrive at >> the list..) > > That's strange, but you are correct in that all mails I have > received from you have been coming directly too me, and none have > arrived through the list. Maybe they are stuck in moderation, but > I don't know the details of that??? > > Anyway, I managed to dig up at least some background, see this thread > > http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html
More background [1], [2]: 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 crap seems to have been added specifically for early (arguably broken) bi-arch enabled GCCs that printed -m32 directories even though -m64 was the default. 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. The thing to look out for could be if any of the -print-search-dirs ends with /$lt_multi_os_dir and use that as an indicator that we have a sufficiently new GCC, and all -print-search-dirs should be left as is (we should probably continue prune those that don't exist, though). I have attached a version that implements the above idea. I feel pretty good about that one actually, but would still like some feedback from someone more familiar with multilib... Or should we just ditch support for those early, arguably broken, bi-arch GCC versions and start trusting -print-search-dirs unconditionally??? Cheers, Peter [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425 [2] http://gcc.gnu.org/ml/gcc/2006-09/msg00184.html
>From c3b6fb587942478acdb65f8a25725f51e61281f2 Mon Sep 17 00:00:00 2001 From: Peter Rosin <p...@lysator.liu.se> Date: Wed, 11 Sep 2013 11:56:56 +0200 Subject: [PATCH] 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. --- 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..bdefd85 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 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 -- 1.7.9
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
