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. 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. > 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. But as you can see from the title of this thread, I do wonder if a different approach is needed. Perhaps your approach is the right one - it would not surprise me if it is. But I think it would be good if whatever method is used, it was used consistently across all platforms - or at least across all Unix and Unix-like platforms. 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
