Hi Mariha, I'm not quite sure what you mean by compiler libraries; libstdc++.so is installed in basically every unix and in the shared library search path (save for embedded, perhaps). Even if you don't have a compiler installed you pretty much need libstdc++.so or you can't run programs that were written in C++. There are a few other libraries that every program will link, like libc.so. Its fair to assume that these are installed on every target machine.
It is also ok if a user installs the pre-compiled binaries and then decides to put his own libraries first in the shared library search path. The new libraries might break something, but at least he gets to keep both pieces. It seems that the only necessary change in the sage build process is to use the gcc shipped with Fedora 12, and not some private install in /usr/local. One could fix the privately installed toolchain to produce .la files that do not hardcode /usr/local/...; But that would be tedious and you'd still risk broken Fedora packages as the compiler version is different from the official F12 gcc. Cheers, Volker On Jan 26, 8:57 pm, Mariah <mariah.le...@gmail.com> wrote: > Volker, > > Much thanks for your explanation. > > So Sage binaries - since they depend on finding > dynamic compiler libraries like libstdc++.so - must be built > using compilers in standard locations on the build > machine, and the target > machines must have those same libraries in the same > standard locations. > > This is certainly possible for Linux distributions (like > Fedora), provided > > 1. that the target machine has the development > package included, (the development package > includes the compiler libraries - but the > development package is not the default install > on many Linux distributions) > > and > > 2. the user has not installed a newer (or > different) compiler suite and put it ahead > in the path and LD_LIBRARY_PATH. > > [Note to whomever builds the Sage binaries using > skynet (specifically skynet/eno in this particular > case) - make sure that you > use the compilers in /usr/bin and NOT the (newer) > ones in /usr/local/bin (that I build).] > > I am not sure what a complete list of necessary > complier libraries might be, but perhaps they > should be added to a requirements list? And perhaps > a Sage binary should check for them? > > An alternate possibility to requiring compiler libraries > in standard locations is to say that Sage binaries > are just for running Sage commands. If you want > to do development work, you should build from source > (in which case Sage will find where the compiler > libraries are on your particular machine). > > If I have things wrong, I hope someone will > enlighten me! > > Mariah > > On Jan 26, 2:43 pm, Volker Braun <vbraun.n...@gmail.com> wrote: > > > > > Hi Mariah, > > > On Jan 26, 6:21 pm, Mariah <mariah.le...@gmail.com> wrote: > > > > I guess I do not understand that "usual drawbacks" to > > > statically linking to which you refer. Can you expand, please? > > > First off all it wastes disk space; I'm trying to make a TOPCOM spkg > > and a naive compile/make/make install will generate 200MB of binaries. > > > The more serious issue is that you can't upgrade the libraries any > > more after they were statically linked. Or, rather, if you do then > > whoever linked to the library does not get updated. > > > > I still am confused about what is not working in Sage. > > > Are you talking about a program external to Sage not being > > > able to dynamically link with the Sage libraries? > > > Yes, exactly. In particular, you can't create new spkgs that > > dynamically link with existing spkgs. > > > Cheers, > > Volker -- 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
