Rules for versioning shared libraries are rather strict _ and they are NEEDED for the proper use of such libraries.
Eg., on MacOSX, the "install_name" can and should remain the same as long as no existing symbol disappears,
and as their old syntax remains valid, with the same semantics. Else the install_name must increase.
Similarly, the compatibility version remains as long as the set of symbols, with their syntax and semantics,
remains the same. (And "current_version" is thereto adjust to other changes.)
On other systems, there are similar rules, and just as stringent: libtool even has an algorithm mapping major, minor
and tiny versions to their MACOSX counterparts.
I am worried to see the testing pakages (3.9.xx) advancing towards stable situation without any sign that this will be
resolved in time.
(And it really should be _ else the shared libs will only be a source of confusion and of errors in the future.)
In particular,any such progress would in my mind probably involve
1) deciding on a specific set of libraries (say -llapack -lf77blas -lcblas -latlas), don't allow any other combination.
2) having an explicit list of exported symbols for each of the 4 libraries (this could then also optionally be used for dead-code elimination when linking)
3) forbidding the use of versions of lapack that are too old to make the above rules unambiguous
(thus, in practice, allow only versions that have exactly the same set of symbols, with same syntax ad semantics, as the most current one.)
4) putting libtool's algorithm somewhere in the code, to automatically decide, for each library and every new build, on its MacOSX's install_name,
compatibility_version and current_version, as a function of Major, minor and tiny versions..
Log in to post a comment.