[Scons-dev] Issue 2869 - Versioned shared libraries

[Managan, Rob]

Hi Chris,

Thanks for the info. Sounds like I should have the Install function check
that the version numbers match. In the use case where Install does not
know what the version number is then I will believe the one in the library
name!

Of course, in the example from Eric Raymond on OSX there is only one
symlink and the version number is located differently.



On 10/25/12 12:56 PM, "Chris BeHanna" <chris at behanna.org> wrote:


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

>

>>...



>>	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

>

>..



>	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

>_______________________________________________

>Scons-dev mailing list

>Scons-dev at scons.org

>http://two.pairlist.net/mailman/listinfo/scons-dev