On Tue, Apr 23, 2013 at 10:21 PM, Brice Goglin <brice.gog...@inria.fr>wrote:
> Le 24/04/2013 00:35, Paul Hargrove a écrit :
> > I took a look at libtool.m4 and find that
> > the sys_lib_dlsearch_path_spec value is HARDCODED as part of big
> > "case $host_os in". That is why the autoreconf resolves the problem -
> > the distro maintainers have customized libtool.m4 appropriately.
> >
> > Other than instructing folks to autoreconf, I don't see a "clean" fix
> > for this issue.
> >
>
> Ok, thanks. So our configure indeed generates libtool script that
> depends on where the tarball was generated. That's a bit disturbing.
>
[snip]
It is not quite as you describe because I was talking about Fedora's
libtool.m4 doing the hardcoding.
The libtool.m4 logic that is distributed with hwloc *tries* to perform a
configure probe to determine the dynamic lib search path.
Unfortunately, that probe isn't smart enough to get the right answer on all
Linux distros.
So, the libtool.m4 from Fedora is the one I see hardcoding the correct
answer.
Again: libtool in the official tarball of hwloc-1.7 does NOT do something
as horrible as hardcode the wrong answer from the distro where one built
the tarball (but it probably would it you built the tarball on Fedora).
It appears somebody has been bugging the libtool developers about this
since June 2010:
http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00141.html
If you read to the end you'll see hwloc was the package in question then
too!
If you follow one of the links in that thread, there is a
patch against libtool-1.5:
http://article.gmane.org/gmane.comp.gnu.libtool.general/8345
which I've just now updated for libtool-2.4.x (and corrected) to get the
desired/correct behavior.
In my testing on Fedora 17, the patch below applied to hwloc-1.7 produces
an accurate sys_lib_dlsearch_path_spec
-Paul
--- config/libtool.m4~ 2013-04-07 16:29:21.000000000 -0700
+++ config/libtool.m4 2013-04-23 22:43:52.882000000 -0700
@@ -2669,10 +2669,10 @@
# before this can be enabled.
hardcode_into_libs=yes
- # Append ld.so.conf contents to the search path
- if test -f /etc/ld.so.conf; then
- lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s
2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' <
/etc/ld.so.conf | $SED -e 's/#.*//;/^[ ]*hwcap[ ]/d;s/[:,
]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '`
- sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
+ # Extract search path from ldconfig
+ ldconfig_search_path=`/sbin/ldconfig -N -X -v 2>/dev/null|$SED
's,^\(/.*\):\( (.*)\)\?$,\1,p;d'|tr '\012' ' '`
+ if test -n "$ldconfig_search_path"; then
+ sys_lib_dlsearch_path_spec=$ldconfig_search_path
fi
# We used to test for /lib/ld.so.1 and disable shared libraries on
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
