Jeff, can you fix the trunk nightly script to use libtool 2.4.2 instead of 2.4 ? Thanks.

Paul, the v1.7 branch nightly and the official v1.7 release tarball use 2.4.2 and I think we have the same problem there too. Rerunning autoreconf with centos63 or fedora17 libtool 2.2.6 seems to fix the problem. What I don't understand is where configure gets this list of directory from. Sleeping may help.

Brice



Le 23/04/2013 23:08, Paul Hargrove a écrit :
I just tried building the hwloc trunk (from a nightly tarball) on Fedora17.
The following lines appear in the libtool script generated by configure:
# Compile-time system search path for libraries.
sys_lib_search_path_spec="/usr/lib/gcc/x86_64-redhat-linux/4.7.2 /usr/lib64 /lib64 "
# Run-time system search path for libraries.
sys_lib_dlsearch_path_spec="/lib /usr/lib "

If I am understanding things correctly, this means that libtool expects that it NEEDS to encode the rpath for libs to be installed in /lib64 and /usr/lib64 because they do not appear in sys_lib_dlsearch_path_spec.

HOWEVER, if I first run "autoreconf --install --force" to use the system-provided libtool:
# Compile-time system search path for libraries.
sys_lib_search_path_spec="/usr/lib/gcc/x86_64-redhat-linux/4.7.2 /usr/lib64 /lib64 "
# Run-time system search path for libraries.
sys_lib_dlsearch_path_spec="/lib64 /usr/lib64 /lib /usr/lib "
Which, I believe, is the desired behavior.

I don't know if fedora has made any significant changes to it, but they are using libtool 2.4.2, which is newer than the 2.4 that comes in the hwloc nightly tarballs.

I know from experience that libtool 2.4.2 fixed a problem in 2.4 in which shared libs were not built correctly with the PGI compilers.  So, I'd recommend updating libtoool regardless of whether doing so resolves the rpath issue reported on Fedora 18.

-Paul



On Tue, Apr 23, 2013 at 1:26 PM, Samuel Thibault <samuel.thibault@inria.fr> wrote:
Brice Goglin, le Tue 23 Apr 2013 19:12:08 +0200, a écrit :
> I assume that libtool doesn't add a rpath when you install in standard
> directories?

Yes, it's doing stuff to detect with paths are actually already in the
standard search dirs.

> If /usr/lib64 is the default path for 64bits libs on Fedora, shouldn't somebody
> take care of removing the corresponding rpath too?

libtool should be already doing that.

> This is likely related (but the reversed case) to the comment about Fedora in
> http://wiki.debian.org/RpathIssue. One link on that page says that rerunning
> libtoolize before configure may help. Can you try that? (maybe compare the new
> libtool script with the one from the hwloc tarball to check that some lib64
> things appeared?)
>
>
>       □ If the application uses a local copy of libtool, add the following
>         lines to the spec after %configure:=> it will make tests FAIL (without
>         this change, it runs just fine - all tests are PASSED)
>
>     FAIL: test-hwloc-annotate.sh
>     FAIL: test-hwloc-assembler.sh
>     PASS: test-hwloc-calc.sh
>     PASS: test-hwloc-distances.sh
>     PASS: test-hwloc-distrib.sh
>     FAIL: test-hwloc-info.sh
>
>
> I am not sure why some fail while the other succeed. You may need to set
> LD_LIBRARY_PATH to fix this?

The libtool script is supposed to automatically add it.

It would probably be worth running by hand to see what actually fails.

Samuel
_______________________________________________
hwloc-devel mailing list
hwloc-devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel



--
Paul H. Hargrove                          PHHargrove@lbl.gov
Future Technologies Group
Computer and Data Sciences Department     Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900


_______________________________________________
hwloc-devel mailing list
hwloc-devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel