Jeff, Thanks for the lengthy explanation. I now understand the situation *much* better. Some portion of your response could become an FAQ for v1.9.
Regarding: > Would you mind testing the OMPI PR branch on this old system? I can make > you a tarball if it would help. If I had new enough autotools to autogen on this old system then I wouldn't have asked about libltdl from libtool-1.4. So, please *do* generate a tarball and I will test (on *all* of my systems). -Paul On Fri, Jan 30, 2015 at 3:49 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com > wrote: > On Jan 29, 2015, at 9:11 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > > > If I understand one is (or will be soon) expected to have > libtool-dev(el) installed on the build system, even if one is not a OMPI > developer. > > No. We don't want to raise the bar that high for simple user > installations. > > If you are installing an OMPI tarball from source (that is not a git > clone): > > 1. If you have libltdl devel support installed (i.e., ltdl.h), then OMPI > will build as it always has: with plugin support. > > 2. If you do not have libltdl devel support installed, then OMPI will > effectively behave as if --disable-dlopen was specified. I.e., there will > be no plugin support and all OMPI plugins will be slurped up into their > upper-level libraries (e.g., BTLs are slurped up into libmpi.so or > libmpi.a). > > Hence, from OMPI tarballs, *OMPI will always build and function correctly* > -- regardless of whether you have libltdl / libltdl-devel. > > I'm guessing that many user installations will now build without plugin > support (because libltdl-devel is typically not installed in Linux distros > / OS X by default). However, after talking this through in Dallas this > week, I'm not thinking that this is a problem. > > > How does this plan to cease embedding libltdl align with the fact that > autogen.pl currently applies patches to the parts of the generated > configure from the *packager's* system? Isn't there now going to be a > disconnect between the versions of libtool-related portions of the > configure script shipped in a tarball and the version (if any) of libltdl > on the system building from that tarball? > > I think that's two questions: > > 1. Will OMPI continue to patch configure/etc. w.r.t. libltdl functionality? > > No; there's no need, because we were effectively patching against the > embedded libltdl. Since we're not embedding, there's nothing to patch. > > We will lose the "bug fix" that we were patching, however (there is a > giant comment in this file that explains what it is for): > https://github.com/open-mpi/ompi/blob/master/config/libltdl-preopen-error.diff > > That may be a bit annoying. ...but then again, if most users are going to > end up not building plugin support, the need for that patch effectively > goes away. > > 2. What happens if OMPI tries to build against an old libltdl? > > We *should* be ok. libltdl has been stable for a long time. libltdl > added the lt_dladvise functionality at one point, but we added configure > tests to check for that a long time ago (i.e., the C code can handle > whether or not your libltdl has support for lt_dladvise). > > This PR actually adds the results of those lt_dladvise configury tests to > ompi_info output. > > > Also, I can still build v1.8 on an old Red Hat 8 system where the system > libtool/libltdl is 1.4.2, perhaps only because Open MPI embeds a recent > version. > > Could be. Would you mind testing the OMPI PR branch on this old system? > I can make you a tarball if it would help. > > > What minimum version of libltdl is required after the proposed change? > > Will I need to install a libtool-2.x on that old system to be able to > build OpenMPI with dlopen support? > > I don't know what the minimum Libtool/libltdl required version is; I > didn't try to back track to find it. > > I think that if we can still build on a sufficiently-old system (e.g., Red > Hat 8 with your LT 1.4.2), that is probably good enough. > > Also, remember: libltdl has *never been required* for Open MPI. Although > building with libltdl has always been the default, you could always have > disabled it. This PR effectively now changes the default to > build-it-if-we-got-it-and-skip-it-if-we-don't for users, and developers > must specify --disable-dlopen if they don't have libltdl-devel (per the > assumption that most developers will want to build with dlopen support). > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/01/16851.php > -- Paul H. Hargrove phhargr...@lbl.gov Computer Languages & Systems Software (CLaSS) Group Computer Science Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
