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.gog...@inria.fr> 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-de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
