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/
