-
Notifications
You must be signed in to change notification settings - Fork 865
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Remove embedded libltdl #366
Conversation
79425da
to
625dec4
Compare
Refer to this link for build results (access rights to CI server needed): Build Log
Test FAILed. |
Refer to this link for build results (access rights to CI server needed): Build Log
Test FAILed. |
@miked-mellanox Can you please install libltdl-devel on the build system (or whatever RPM includes ltdl.h)? |
Also need to warn all MTT installations! |
retest this please |
Refer to this link for build results (access rights to CI server needed): |
done, btw on rhel 6.5 it is libtool-ltdl-devel |
Yes, good point -- MTT installations as a good barometer for what will happen in the rest of the world... I.e., I'll bet that that with this RFC, many (most?) users will effectively be building with --disable-dlopen. This may not be a tragedy, though. |
625dec4
to
a8ce0fc
Compare
maybe --disable-dlopen should be the default than? |
Refer to this link for build results (access rights to CI server needed): |
There is an assumption that developers will highly value dlopen functionality. See what I just posted here: http://www.open-mpi.org/community/lists/devel/2015/01/16851.php Actually, I take back what I said above: if MTT installations are only testing tarballs, they won't see this problem (because they'll all build with |
Refer to this link for build results (access rights to CI server needed): |
9f0b3fc
to
b429e2a
Compare
Refer to this link for build results (access rights to CI server needed): |
b429e2a
to
1be0cfd
Compare
Refer to this link for build results (access rights to CI server needed): |
1be0cfd
to
66b383f
Compare
This PR is one option for fixing #311. |
Refer to this link for build results (access rights to CI server needed): |
278853d
to
6044741
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Per open-mpi#311, Libtool v2.4.4 exposes a bug in either Libtool and/or autoreconf (after discussions with Libtool and Autoconf maintainers, it's not clear which) when embedding libltdl. After some discussion in the Open MPI community, we have decided to both remove our embedded libltdl and (mostly) treat libltdl like any other external library: * If --disable-dlopen is specified, it behaves as it always has: libltdl support is wholly disabled, and all plugins are slurped into their higher-level libraries. * If --enable-dlopen is specified, configure will abort if it cannot find proper libltdl support. * If neither of these are specified, configure will behave differently between a developer build (i.e., where a .git directory is present in the source tree) and non-developer build: * In a developer build, --enable-dlopen is assumed (i.e., configure will abort if libltdl support cannot be found). --disable-dlopen must be specified if you do not have libltdl support. * In a non-developer build: * If configure finds libltdl support, it will behave as if --enable-dlopen was specified. * If configure does not find libltdl support, it will behave as if --disable-dlopen was specified. The developer build behavior is because dlopen support is usually highly valued (e.g., being able to repeatedly build individual plugins), and libltdl-devel may not be installed by default on Linux distros and OSX. Hence, without this special developer-build provision, developers may inadvertently build without dlopen support. Fixes open-mpi#311.
6044741
to
dd30ed4
Compare
Refer to this link for build results (access rights to CI server needed): |
Per discussion on the 17 Feb 2015 Tuesday webex, we have decided to use the "embed libltdl" approach (i.e., #390) instead of this "remove libltdl" approach. So I'm closing this PR. |
…_typos v1.8: fortran typos
Per #311, and per the discussions in the Dallas OMPI dev meeting, remove the embedded libltdl from Open MPI.
There are two minor commits and then the major commit of removing the libltdl:
There was some discussion in Dallas about what the default should be if libltdl support is not found on a machine when building Open MPI. Here's the behavior defined in the initial version of this PR, which I think gives a good compromise of what everyone wanted:
--disable-dlopen
is specified, it behaves as it always has: libltdl support is wholly disabled, and all plugins are slurped into their higher-level libraries.--enable-dlopen
is specified, configure will abort if it cannot find properl libltdl support.--enable-dlopen
is assumed (i.e., configure will abort if libltdl support cannot be found).--disable-dlopen
must be specified if you do not have libltdl support.The developer build behavior is because dlopen support is usually highly valued (e.g., being able to repeatedly build individual plugins), and libltdl-devel may not be installed by default on Linux distros and OSX. Hence, developers may inadvertently build without dlopen support without this special developer-build provision.