orted-mpir: add version to shared library

[ahesford]

Because orted-mpir is installed in the public library direrctory, it should have a version. Assign the library libopen_rte_so_version to be consistent with the rest of the RTE.

This is important, e.g., for Void Linux, which tracks shared library versions to avoid broken dependencies. Void splits the core libraries into a libopenmpi package so other packages can link against it and avoid pulling in the entire OpenMPI runtime should users not with to use the capability. The runtime modules in /usr/lib/opempi are shipped with the broader openmpi package, and the package system must track the libopen-orted-mpir.so dependency between these two packages at least.

This may need backporting to v4.0.x and earlier.

bot:notacherrypick

[ompiteam-bot]

Can one of the admins verify this patch?

[awlauria]

ok to test

[awlauria]

@ahesford can you re-push after your amend your commit with -s.

git commit --amend -s should do it.

[ahesford]

Commit amended

[bwbarrett]

Why are we installing that library at all? Isn't it supposed to be a helper library to avoid CFLAGS?

[ahesford]

I believe the only reason this library exists is to avoid CFLAGS.

The linker seems to pull it as a dependency in several runtime mca modules in /usr/lib/openmpi and the public libraries

/usr/lib/libmpi.so.40.30.1
/usr/lib/libmpi_usempif08.so.40.30.0
/usr/lib/libmpi_mpifh.so.40.30.0
/usr/lib/libopen-rte.so.40.30.1

[awlauria]

Yes, it is only to avoid the global CFLAGS, which would optimize out certain MPIR functionality in optimized builds.

It was done to not blow away CFLAGS for other files that still want the CFLAGS optimizations.

[bwbarrett]

Yes, it is only to avoid the global CFLAGS, which would optimize out certain MPIR functionality in optimized builds.

It was done to not blow away CFLAGS for other files that still want the CFLAGS optimizations.

Then this PR is the wrong fix. Rather than setting a version, we should make this library a noinst_ library and not worry about versioning.

[ahesford]

I made the noinst change. If this is definitely the right solution, I can squash the commits for merge. Otherwise, if somebody has a compelling reason to install the library, we can drop the second commit and use the original solution.

[awlauria]

LGTM.

[bwbarrett]

I made the noinst change. If this is definitely the right solution, I can squash the commits for merge. Otherwise, if somebody has a compelling reason to install the library, we can drop the second commit and use the original solution.

The first patch is not necessary. noinst libraries should not be versioned in OMPI. And if we are going to version them, it shouldn't piggyback off of another library's version string, but have its own. So please don't squash; just drop the first patch.

[ahesford]

The second patch reverted the first and made the library noinst, so squashing was equivalent to dropping the original patch. All done.

[awlauria]

@ahesford did you want to cherry-pick this to the v4.0.x branch?

[ahesford]

I think it makes sense to cherry-pick to v4.0.x. Is there something special I need to do to facilitate this?

[awlauria]

You should just need to add -x to the cherry-pick.

[ahesford]

OK, #8912