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:
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:
> 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.
> hwloc-devel mailing list
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/