]> git.ipfire.org Git - thirdparty/libtool.git/commit
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)
commit0ebb734910bf56186dd0c0e84b1c8be507bad336
tree7713c8a631ab292dfe5000b80e313d866c790d4a
parent75051fb536aa3a84324f61253765ab0e58e91fa2
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
m4/libtool.m4