config: fix libmpi_abi.so version-info so the intended SONAME is applied#7867
Open
jsquyres wants to merge 1 commit into
Open
config: fix libmpi_abi.so version-info so the intended SONAME is applied#7867jsquyres wants to merge 1 commit into
jsquyres wants to merge 1 commit into
Conversation
The -version-info value for libmpi_abi was never reaching libtool, so the library was installed as libmpi_abi.so.0 (libtool's default when no -version-info is given) instead of the intended libmpi_abi.so.1 encoded by libmpi_abi_so_version_m4 (1:0:0) in maint/version.m4. Two independent bugs caused this: 1. configure.ac referenced the macro as "libmpi_abi_so_verion_m4" (missing the "s" in "version"). That macro is undefined, so m4 left the literal token in place; ABI_ABIVERSIONFLAGS ended up holding the bogus string "-version-info libmpi_abi_so_verion_m4". 2. ABI_ABIVERSIONFLAGS was never AC_SUBST'd, so even that bogus value never reached the Makefiles. $(ABI_ABIVERSIONFLAGS) expanded to empty on the libmpi_abi link line, and libtool fell back to its 0:0:0 default. Fix the macro name so it expands to the 1:0:0 defined in maint/version.m4, and AC_SUBST/export ABI_ABIVERSIONFLAGS the same way ABIVERSIONFLAGS already is, so the value flows through to the link line. With this change libmpi_abi installs with an SONAME of libmpi_abi.so.1. Setting the SONAME to match MPI_ABI_VERSION (so every implementation of ABI version 1 exposes libmpi_abi.so.1, and applications can switch backends) is the intent behind the 1:0:0 value; see the discussion in mpi-forum/mpi-abi-stubs#28 and the Open MPI ABI PR (open-mpi/ompi#13280).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
libmpi_abiis currently installed with an SONAME oflibmpi_abi.so.0even though
maint/version.m4setslibmpi_abi_so_version_m4to1:0:0(which should yieldlibmpi_abi.so.1). The intended-version-infonever reaches libtool, so libtool falls back to its0:0:0default. Two independent bugs cause this:Typo.
configure.acreferenced the macro aslibmpi_abi_so_verion_m4(missing thesinversion). That macrois undefined, so m4 passes the literal token through — you can see it
survive verbatim into the generated
configure:Missing
AC_SUBST.ABI_ABIVERSIONFLAGSwas neverAC_SUBST'd(unlike
ABIVERSIONFLAGS), so even the bogus string never reachedthe Makefiles. In the generated
Makefile,$(ABI_ABIVERSIONFLAGS)expands to empty on the
lib_libmpi_abi_la_LDFLAGSline, and libtoolapplies no
-version-info→ default0:0:0→libmpi_abi.so.0.Fix
1:0:0already defined inmaint/version.m4.exportandAC_SUBSTABI_ABIVERSIONFLAGS, exactly asABIVERSIONFLAGSalready is, so the value flows to the link line.With this change
libmpi_abiinstalls with SONAMElibmpi_abi.so.1,matching the
1:0:0intent already encoded inmaint/version.m4.Why
libmpi_abi.so.1The point of the standard ABI is that an application can switch backends
without recompiling, which requires every implementation of a given ABI
version to expose the same SONAME. Setting the SONAME to match
MPI_ABI_VERSION(so ABI v1 →libmpi_abi.so.1everywhere) is whatmaint/version.m4's1:0:0already intends; this PR just makes it takeeffect. See the versioning discussion in mpi-forum/mpi-abi-stubs#28 and
the Open MPI ABI work in open-mpi/ompi#13280. (Open MPI is setting its
libmpi_abiSONAME to.so.1to match.)Verification
Verified by structural analogy: the sibling
libmpi_so_version_m4usesthe identical
m4_define/ expansion idiom in the sameversion.m4andresolves correctly (
ABIVERSION = 0:0:0in the generatedMakefile);this change makes
libmpi_abi_so_version_m4flow the same way. A CIbuild with
--enable-mpi-abishould confirm the installedlibmpi_abi.so.1SONAME.Notes / possible follow-up
This PR intentionally keeps the hard-coded
1:0:0inmaint/version.m4and only fixes the plumbing so it applies. Deriving the
c:r:atripletprogrammatically from
MPI_ABI_VERSION/MPI_ABI_SUBVERSION(per theformula in mpi-abi-stubs#28) would be a larger, separate change and is
left out here.