-1 from me to including these libraries. Q1. Are there any other well-known packages which do this? If not, it is not a standard thing to do, probably for good reason.
Cython uses the C compiler (if I understand correctly). I think this kills the idea dead. Q2. Would building Sage with the Sun CC compiler remove the need to have standard GNU libraries accessible somewhere? If so, how hard would it be to have Sage build with the Sun CC? Bill. On 22 Feb, 20:44, "Georg S. Weber" <georgswe...@googlemail.com> wrote: > On 22 Feb., 12:27, "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. > > > 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 staff 80K 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? > > > Dave > > Hi Dave, > > this only is reasonable, if for building Sage we do not use the (or > "a") "system's default compiler". So on GNU/Linux, or Mac OS X, this > is almost a non-issue --- it's clear what this default compiler is, > and Sage uses it. > > It's far less clear on Solaris, or e.g. on Windows. If some future > Sage is built with some Microsoft Visual C++ compiler, we will have to > tell the casual user exactly which additional msvc libraries (for msvc > 2008, or 2010, or ...) need to be installed on a "virgin" Windows in > order for Sage to be able to run. (These additional libraries are free > for download, but not free to distribute by others than Microsoft.) > But then, these libraries will be installed in some system location. > > Back to the Solaris case --- as long as we do not have some "GCC > spkg", eventually optional, that installs the full GCC, I'm opposed to > install its compiler specific libraries under $SAGE_ROOT. Instead, > Sage should rely on them to be found in the standard system locations > --- or in the ones the user explicitly communicates to Sage via > environment variables. > > Of course it would make sense to provide for Solaris some "minimal GCC > library install" specifically adapted for the need of potential Sage > users. > (Just like in the case of Microsoft not urging users to install the > full msvc, but providing some library-only package.) But IMHO, this is > outside the scope of our current model of fully relocatable yet > "open" (Sage) installs, so that would need to be offered somewhat in > parallel. (Otherwise, Sage would need to be yet far more paranoid > about taking in which dynamic libraries and how than today, see also > Robert's remark.) > > Cheers, > Georg -- 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
