On Thu, Dec 17, 2009 at 3:13 AM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > François Bissey wrote: >> On Thu, 17 Dec 2009 16:45:36 Dr. David Kirkby wrote: >>> This is not simply a run-time issue, as the conflicts are causing a failure >>> of Sage to build on OpenSolaris. >>> >>> http://trac.sagemath.org/sage_trac/ticket/7387 >>> >>> I'm not convinced renaming the libraries would solve it - as you say, it >>> might introduce other problems. In fact, I'd take a guess it would be >>> highly likely to introduce other problems. >>> >> I had forgotten this little pearl of yours with gnutls. For what its worth >> with the port of sage to Gentoo we rely on system provided packages >> as much as possible - in fact the goal is to build sage on Gentoo >> bypassing completely the usual sage building process. > > Hi François, > > I've never run Gentoo linux and have not run Linux much, so I am not saying > your > approach of using system libraries, rather than Sage libraries is wrong. In > fact, your approach is more typical of how most software packages are built. I > do not know of any other where the source file consists of virtually all the > software needed to build a package.
Commercial software is sometimes built this way... but you'll never know :-) > But here are a few comments about your approach. > > * One problem I could foresee is when a user finds a problem, it is more > difficult to know if it is because their system version of a library is too > old, > or otherwise incompatible with Sage. There are already many reports of things > not working on version X.Y of distribution Z. Sage developers try to sort > these > out. I suspect it would make things a lot more complex if the developers do > not > know what library versions a user with a bug report is using. It's not unusual > to find only certain versions of libraries work, and one too old, or too new, > will not present problems. > > Unlike gcc where you can type > > gcc --version > > to find the version number, I'm unaware in general of doing that with > libraries. > That must make things more complex to debug. > > * It is also inconsistent with the rest of the Sage builds. It seems to add > complications, if Sage is built one way on one version of Linux, and another > way > on every other Unix or Unix-like system. > > If you were porting to VMS, then I could see that having one method for > Unix-like systems and another for VMS might be quite reasonable. Likewise I > can > see the logic for Windows. But I'm less convinced myself about the wisdom of > using a different approach on Gentoo, then on any other Unix or Linux system. Well the default sage-x.y.z.tar source distribution will continue to build the same way on Gentoo as everywhere else. François is just properly integrating a Gentoo-provided Sage into the Gentoo environment. This is exactly like Tim Abbott integrating Sage into Debian. >> So far we have removed almost everything that isn't python related and >> it seems to mostly work. Of course some stuff doesn't work/isn't expected >> to work like sage -br or sage -upgrade. But if you want to use those you >> probably don't want to use a version of sage packaged for your distro. > >> The point is - in my experience working with a certain number of system >> provided packages - apart from python - usually works well in practice >> possibly with some adjustment to sage-env. > > You do not surprise me this works well - it is the way most software is built. > Sage is pretty unique in the way it includes the sources to everything. I > can't > think of another package which works this way. But then I can't think of any > other package that has so many dependencies as Sage, so I can understand > William's logic in taking the approach he did with Sage. > >> Of course checking whether you can use a system package rather than >> the sage provided one is a big complication, which would get lots of -1 >> if suggested. But it is nice to know that it is actually doable. > > Yes, I can imagine you would get lots of -1's. It wouldn't be so bad to try this but have it *off* by default, and make it so one can turn it on with an environment variable. > I wonder if the problem could be solved by a deep understanding of the link > process, and the correct use of the numerous options linkers have. This is the > list for the GNU linker > > http://sourceware.org/binutils/docs-2.20/ld/Options.html#Options > > The following look as if they just might help, but I do not have the knowledge > to use them properly. > > --whole-archive > --no-whole-archive > --dynamic-linker > --export-dynamic > --no-export-dynamic > -soname > --undefined > --discard-all > --discard-locals > --start-group archives > --end-group > > That last two in particular are related to "unavoidable circular references > between two or more archives", which might mean the sort of issues I have seen > on OpenSolaris. > > Dave > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
