Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

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

Le 24/04/2013 08:05, Paul Hargrove a écrit :
> Ok, thanks. So our configure indeed generates libtool script that
> depends on where the tarball was generated. That's a bit disturbing.
> 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).

Well, it's the same idea in the end. The libtool.m4 in the hwloc tarball
is placed there by autoreconf, so it comes from the Debian machine where
I generate the tarballs. I could generate official tarballs on Fedora to
work around the issue (some nightly builds are generated this way, but
not the official ones from the website (RHEL4 iirc).

> It appears somebody has been bugging the libtool developers about this
> since June 2010:

That "somebody" is the person who opened this hwloc thread yesterday :)

> In my testing on Fedora 17, the patch below applied to hwloc-1.7
> produces an accurate sys_lib_dlsearch_path_spec

It's crazy that this hasn't been resolved earlier. Many projects may
have the same problem. Maybe many of them ignore it because they build
their tarballs on distros with a patched libtool.

Anyway, we can't easily patch hwloc's libtool.m4 since we'd have to do
that during autogen (after libtool.m4 gets copied), and the patch may
fail against some versions of libtool. We could patch during the release
tarball generation since we enforce the libtool version there, but I
still don't fully like the idea.

Let's see if Jirka can work around the problem by autoreconfing during
the RPM build and ping the libtool maintainers to finally fix this.