On Sep 26, 12:28 pm, Martin Albrecht <[EMAIL PROTECTED]>
wrote:
> > > - "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?
Well, in theory: yes. But autoconf does not work on Windows and
various spkgs do neither use autoconf or SCons. And I do not want to
move more code to use autoconf since IMHO it plainly sucks. There are
alternatives that work on Windows for sure, but that is likely even
more work since few people use SCons for example. One can always have
two build systems, i.e one for Windows and one for the rest.
> > > - "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.
But the above problems do also cause trouble when I upgrade an spkg
when doing merges, i.e. if I updated ntl I would hate to rebuild all
of Sage. As is the soname of FLINT is changed *every* time the minor
version is bumped.
> > > - "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.
I agree, but there is a shitload of unpackers out there that are plain
stupid. It does not have to be traditional tar.
>
> > > - "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.
*Every* DLL on that list is rebase, it does not matter if they are
loaded or not. And that causes address space fragmentation.
> > > 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).
I strongly disagree. gmp for example provides no versioning info at
all on Windows when using either MinGW or Cygwin and you can be sure
that TG is not someone who prefers not to do the "right thing". It is
plainly just not worth it in Sage to put up with all the added
complexity if we don't even use the functionality. I don't mind if the
packages we use provide soname & friends, I just don't want to use
them in Sage since that makes the job of porting significantly easier.
And the fact that every patch so far that provided sonames has broken
the build on BSD and Solaris depsite me pointing out that this causes
problems over and over again should tell you that getting it right is
hard :).
> Cheers,
> Martin
Cheers,
Michael
> --
> 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
-~----------~----~----~----~------~----~------~--~---
