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: Jiri Hladky (hladky.jiri_at_[hidden])
Date: 2013-05-07 12:38:08


Thanks a lot for all the feedback !!!

I went with
autoreconf --force --install

which solved a problem.

@Jeff: the versions of your quadtuple looks good to me! I'm using the same
with the exception of automake (1.12.2 which is even older than yours).

I have now successfully created rpm for hwloc 1.7 for Fedora.

Jirka

On Wed, Apr 24, 2013 at 2:52 PM, Jeff Squyres (jsquyres) <jsquyres_at_[hidden]
> wrote:

> I'm a little late to this thread, but I just changed the build machine to
> build hwloc trunk tarballs with the same versions of Autotools as the v1.7
> tarballs:
>
> AC 2.69
> AM 1.13.1
> LT 2.4.2
> GM4 1.4.16
>
> Let me know if that's good. If not, I can install any quadtuple (use that
> in a sentence today) of versions that we need.
>
>
>
> On Apr 24, 2013, at 3:48 AM, Brice Goglin <Brice.Goglin_at_[hidden]> wrote:
>
> > 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:
> >>
> http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00141.html
> >
> > 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.
> >
> > Brice
> >
> > _______________________________________________
> > hwloc-devel mailing list
> > hwloc-devel_at_[hidden]
> > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>
>
> --
> Jeff Squyres
> jsquyres_at_[hidden]
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
>