> > - "Sage in general does not benefit from versioned libraries" > > > > Is adding a proper soname / library versioning to a library what you call > > versioned libraries? Isn't that somehow standardised and good practice? > > Sure, on Linux and some Unix platforms. But doing it right, i.e. for > non-GNU linkers is complicated. I do not oppose using soname & > friends, but if we introduce them they ought to work on more than > Linux :)
Agreed. So the main objection is improper use of soname and friends by not using autoconf or whatever the currently popular wanna-be autoconf-killer is? > > - "indeed they case a bunch of problems when linking extensions" > > > > Why? > > For example: Take the FLINT.spkg - ever since we used the patches Tim > submitted the spkg was broken twice by either not adjusting the link > name for libfint.so or after installing an updated version Sage would > no longer start since we linked against libflint-1.0.13.so. We do need > to force a rebuild of the extensions that link against FLINT anyway, > so this is manageable, but just imagine what happens if we changed > ntl. Version numbers are supposed to change whenever binary incompatibility is introduced so changing the name actually helps. Also, when upgrading Sage we're rebuilding the library anyway. The not adjusted linkname can be fixed by using proper autoconf and friends. > > - "due to the links the archives get larger" > > > > Do you mean the symbolic links? I don't see how they contribute to the > > size significantly. > > Not the link, but not all tar utilities are smart enough to deal with > links properly. And saving a hundred or so MB install size seems to > matter. Which 'tar' tool doesn't understand symbolic links? That should be a crime. > > - "and on top of that it makes the memory address space on Cygwin even > > more scare" > > > > Can you elaborate on that? > > Cygwin is stupid and often causes libraries to have collisions in > address space. So when you compile a bunch of DLL extensions for > Python (even Python's own) you need to rebase all the DLLs that can be > potentially loaded from an application. In Sage's case we are talking > about 190 extension in addition to numerous other DLLs. For example: > as is if I build Python 2.5 on my Cygwin install Python fails to start > since the socket extension has a address conflict with another DLL. So > one needs do drop out of all Cygwin shells and use the ash shell and a > script rebaseall (which in turn calls rebase.exe) to rebase all > libraries. To be 100% save you need to drop out of the build process > and rebase all DLLs everytime we build a native Python extension. > > On top of the above the total address space on Cygwin is limited to > 1.3GB. So having mutliple DLLs due to symlinks and sonames we > constrict *and* fragment the available address space even more. We still only link *one* version -- say foo.so pointing to foo.so.1.2 -- so I don't see how we populate the limited 1.3GB address space with redundant libraries. > > To me this seems to be an issue that is better discussed first. Quite > > likely, you have very good arguments for the statements above (and you > > know way more about this than I'll ever know), but I would like to hear > > them first. > > Well, all of the above IMHO clearly adds up to the conclusion I > arrived at :). I am not saying versioned libraries are bad in general, > but for the Sage project the disadvantages way outweigh the benefit. > So while versioned libraries are essential for the Debian project they > are a hassle for the Sage project. So far it seems to me that all of your remarks above can be addressed by proper versioning (via autoconf and friends). Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
