On Oct 25, 2012, at 14:42 , "Managan, Rob" <[email protected]> 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
[email protected]
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
