Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#76 library versioning

open
None
5
2012-10-09
2012-01-25
No

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

Best,

Jean-Francois

Discussion

    • labels: --> 2276339
     
    • assigned_to: nobody --> rwhaley
     
  • Jean-Francois,

    Yes, I have put off messing the dynamic install while I try to get ATLAS passing all tests on a variety of platforms. The reason I haven't started the redesign is that I have yet to see user enthusiasm for any design that I can support. You can see the developer discussion at:
    https://sourceforge.net/mailarchive/message.php?msg_id=28515215
    my last design (for linux) is way towards the end of that thread, and had essentially no comments.

    What I need is for someone on each platform of interest (linux, MacOS X, Windows) to help me understand the platform-specific issues, and refine the design. I can then implement, but someone else who actually uses dynamic libs has to sign up to test it for me, or I can't see the point of doing all this work in order to put in an untested method to the stable release.

    I agree with you that having a well-defined shared lib policy would be a huge help for ATLAS users, and I am willing to work on it, but I must have serious help from people who use dynamic libs if any progress is to be made.

    Are you volunteering to help on OS X? If so, you'll need to read the general developer thread, as most of that stuff is not linux-specific, then I'll need to get OS X-specific info from you (expand on versioning explanation above, etc).

    The export list is problematic. LAPACK doesn't have a defined API, unfortunately, so the entire lib is an export list AFAIK, and unfortunately they change it without warning during random releases, and I have no control over that.

    The BLAS are easier, since the BLAS API is all we really need. However, some people do call the internal names (ATL_*), though they are not part of any official API. We can probably get away with only exporting the blas names, but I might get suprised by some users when it is tried.

    In short, I would very much like to improve ATLAS dynamic library support, but I will need partners willing to help if it is to be done. The reason ATLAS has any support at al for dynamic builds is because Pearu Peterson worked with me a long time ago to make it happen.

    Let me know,
    Clint

     
  • I am quite willing to help with anything OSX-related..
    Do have some experience with this, a.o. since all atlas-related fink packages
    (a.o., all octave derivatives) do build using the shared libs.

    Any reasonable and standard scheme for linux should be easily parameterisable to apply as well to MacOSX.

    I guess I better try to deal with the specific points you mention in the e-mail-thread you described. Will do.

    Best,

    JF

     
    • labels: 2276339 -->
     
  • Moving this to feature request, since I didn't get enough understanding to implement dylib versioning in this release.