On 2010-Feb-22 11:27:40 +0000, "Dr. David Kirkby" <david.kir...@onetel.net> wrote: >This came up on the thread "mercurial on t2" but I thought I'd start >a new thread on it. I'd propose that we include in any binary >distribution gcc's C, C++ and Fortran shared libraries. They would be >placed in $SAGE_LOCAL/lib. Then we can ensure that people will run >Sage with what libraries Sage was built with, rather than what >versions they may or may not have lying around.
This is a very difficult question since there are strong pros and cons. My suspicion is that this might wind up needing to be answered on a case-by-case basis. On 2010-Feb-22 05:19:01 -0800, Volker Braun <vbraun.n...@gmail.com> wrote: >If you want to go that route you probably want to include glibc >(contains standard math library) as well. While a viable possibility, >there are two obvious arguments against it: Whilst the math parts of glibc would definitely help, actually including the kernel interface parts of glibc is likely to cause more problems than it solves due to subtle differences in the kernel ABI across different kernels. On 2010-Feb-22 10:46:38 -0800, Robert Bradshaw <rober...@math.washington.edu> wrote: >Perhaps we should check to make sure the libraries are at least >installed at first startup, but is this really a common occurrence? If >not, I'm not convinced we should do something that might cause weird >issues for everyone to cater to the 1% of users who have a strange, >custom *nix build on odd hardware. It's not just that the libraries are installed but that the installed libraries match Sage. This latter point is somewhat more difficult - especially given the fluidity of the g++/libstdc++ ABI. On 2010-Feb-23 00:48:51 -0800, Kasper Peeters <kasper.peet...@googlemail.com> wrote: >I personally think that this is a _very_ bad idea. As others have >emphasised, most systems out there have a proper package management >tool, which can moreover take care of dependencies. Note that Solaris is one of the systems which doesn't come with a proper package management system. > By doing all that >yourself, you also burden yourself with the task of keeping the >Sage-packaged external programs and libraries up to date. Agreed - and Sage has that issue now with the variety of applications it ships with. But by shipping the libraries, you also get rid of a lot of support questions caused by the the installed libraries not being suitable for Sage. And in the specific case of the compiler libraries, there's no additional support burden - Sage just ships whatever it was compiled with. On 2010-Feb-23 09:48:33 -0800, William Stein <wst...@gmail.com> wrote: >How many major software projects with a similar level of complexity to >Sage actually do this? I can think of exactly one: Open Office. That >project is at least as complicated as Sage (maybe more). OOo does a mix of requiring dependencies to be pre-installed and embedding them in its own build environment. System dependencies include Xorg, perl, gmake, bzip2, jdk, bison, tcsh, zip, unzip, GNU coreutils, GNU patch, bash, imake, GNU tar, gperf, Apache ANT and, optionally, seamonkey, KDE, Gnome, freetype, icu, cups. It embeds things like agg, berkeleydb, beanshell, boost, cairo, curl, dmake, epm, expat, icu, jpeg, libxml2, lucene, neon, nss, openssl, python, saxon, stl, Apache tomcat, vigra, xmerge, xpdf, zlib. Despite (or maybe because of) this combination, OOo is very fragile to build. For several years, OOo on FreeBSD has it's own gcc port because it was so sensitive to compiler changes. >Are there any Open Office devs reading this? Doesn't the >OpenOffice project have dozens of fulltime developers, employed by IBM >and Sun? Sage still has 0 fulltime devs. OOo is a opensource version of StarOffice - which is a commercial product. I'm not sure how much paid developer effort goes into OOo. -- Peter Jeremy
pgpzYUfHimkIl.pgp
Description: PGP signature
