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) <jsquy...@cisco.com > 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.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/ > >
