Re: [sage-devel] Add 'gcc' libraries to Sage binaries ( 0.5% bloat)
On 2010-Feb-22 11:27:40 +, 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
Re: [sage-devel] Add 'gcc' libraries to Sage binaries ( 0.5% bloat)
On Mon, Feb 22, 2010 at 11:27:40AM +, Dr. David Kirkby 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. The amount of bloat this would add to the binary would be very small. For Solaris, the compressed sizes of the files are: -rwxr-xr-x 1 drkirkby staff 1.5M Feb 22 10:10 libstdc++.so.6.0.10.gz -rwxr-xr-x 1 drkirkby staff 717K Feb 22 10:10 libgfortran.so.3.0.0.gz -rw-r--r-- 1 drkirkby staff80K Feb 22 10:10 libgcc_s.so.1.gz snip The C library is the one people most likely will have, but given it is by far the smallest, we might as well include it to be 100% sure. Note that libgcc_s is not the C library at all, it is a gcc library containing some support infrastructure for certain features, such as C++ exception handling. (In particular, it is used for ensuring C++ exceptions can cross library boundaries.) This text describes RedHat's policy on libgcc_s and libstdc++: http://kbase.redhat.com/faq/docs/DOC-8313 It seems to suggest that if we want to include libstdc++ or libgcc_s, we should include both. -Willem Jan -- 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
Re: [sage-devel] Add 'gcc' libraries to Sage binaries ( 0.5% bloat)
On Feb 22, 2010, at 3:27 AM, Dr. David Kirkby 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. The amount of bloat this would add to the binary would be very small. For Solaris, the compressed sizes of the files are: -rwxr-xr-x 1 drkirkby staff 1.5M Feb 22 10:10 libstdc++.so. 6.0.10.gz -rwxr-xr-x 1 drkirkby staff 717K Feb 22 10:10 libgfortran.so. 3.0.0.gz -rw-r--r-- 1 drkirkby staff80K Feb 22 10:10 libgcc_s.so.1.gz So adding all 3 adds 2.3 MB of extra code to the binary. But given the binary is 500 MB (not untypical), that is less than 0.5% of bloat. By doing this, we ensure that people * Always have the libraries. * Always have the exact same versions Sage was built with. I believe the Fortran library might already be included for Linux (I have not checked), but I'd suggest all 3 were added to binaries. The C library is the one people most likely will have, but given it is by far the smallest, we might as well include it to be 100% sure. Comments? Are there issues if the gcc and core C libraries don't match? For example, If a user uses cython in the notebook, will it pick up the users g++ and Sage's libstdc++? What about someone who starts with a binary then starts developing with it or installs optional packages? I guess a lot of binaries statically link the core C libraries in, which of course doesn't make sense for us. On the other hand, a quick google search seems to indicate that not even Firefox ships with libstdc++, and the link at http://kbase.redhat.com/faq/docs/DOC-8313 seems to indicate that shipping core libraries is rarely the right thing to do, and great care is made to keep them backwards compatible. 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. - Robert -- 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
