Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [hwloc-devel] RPATH issues when building in Fedora 18
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2013-04-23 18:05:16


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_at_[hidden] <mailto:samuel.thibault_at_[hidden]>> 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_at_[hidden] <mailto:hwloc-devel_at_[hidden]>
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>
>
>
>
> --
> Paul H. Hargrove PHHargrove_at_[hidden]
> <mailto:PHHargrove_at_[hidden]>
> 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_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel