[Scons-dev] Issue 2869 - Versioned shared libraries

[Chris BeHanna]

On Oct 25, 2012, at 14:42 , "Managan, Rob" <managan1 at llnl.gov> wrote:


> Bill and Dirk,

> 

> I think I tend to agree with Bill that Install should not surprise the user. For ease of finding the functionality I will look at adding InstallVersionedLibrary so it naturally sorts along with Install and InstallAs. I suppose I can try to make it smart enough to figure out if the file it is copying has the version number in it or not.

> 

> The one downside I see with that is a user providing a different version number in the Install than he used in building the library. 

> 

> That raises another question since I don't normally deal with these. Is there a real need to build the library with the version number in the local space for testing purposes? Or do people normally build the library w/o version number and then add version number and sym links only when they install it in the system location? In other words, is there a real need for SHLIBVERSION?? I suppose so since Eric Raymond went to the effort to write his function.


	SHLIBVERSION gets baked into the shared library via its .dynamic section's SONAME field (for ELF, anyway), so that programs that are linked against the library will fail to even start if the major version number has changed (which is a change that means "we have non-backwards-compatible changes in here that will probably break your program").

	This goes hand-in-glove with the notion of semantic versioning described here:
	http://semver.org

Shared library versions thus are not merely decorative parts of the filename.  They are an important part of assembling a software system, in that they instantly short-circuit the kinds of maddening, difficult-to-debug problems that one might otherwise have if one blindly tries to use a dynamically-linked program with an incompatible version of the library:  the program immediately receives a SIGKILL from the run-time linker, and that's that.

	One could solve the mismatched-version-passed-to-Install under the covers, without the use of a flag, if Install knew to look for SONAME whenever it was installing a shared library.  If you want instead to give it a hint (to make the coding easier), you could use a flag like VERSIONED=True or something, and have the code provide the .so and .so.$MAJOR_VERSION symbolic links.

	In my own build system, I use an InstallVersionedSharedLibrary() pseudo-builder that creates the symlinks, but it suffers from the same problem:  it does not check that the versions it was given match the ones that were used to build the library, nor does it check against SONAME (which, again, is ELF-specific--it won't work on Windows or on Mac OS X).


> Thanks for the comments, Dirk. I had cleaned things up a little but like the idea of more encapsulation. I really wanted to get a trial balloon out there since it at least worked.

> 

> Am I correct that changing the target name so that the real file includes the version number and the original target name is now a sym link is OK?

> For example, w/o SHLIBVERSION, you get libtest.so, with it you get libtest.so.2.5.4 and lib test.so is a sym link. I did it that way since the provided method did that.


	Yes, libtest.so should be a symlink, but you will also, in a proper setup, need libtest.so.2 as a symlink, because if the library was built correctly with a SONAME of libtest.so.2 (per the semantic versioning notion described above), then programs (which, at link time, recorded their libraries'  SONAMEs as NEEDED fields in their own .dynamic sections) will fail to run when the run-time linker fails to find libtest.so.2 somewhere in its search path.

-- 
Chris BeHanna
chris at behanna.org