Fedora 12 build: lib/*.la broken
Volker Braun
sage-4.3.1-linux-fedora12-x86_64-Linux. Specifically, all c++
libraries have a dependency on
/usr/local/gcc-4.4.2/x86_64-Linux-core2-fc-binutils-2.20/lib/../lib64/libstdc++.la.
C-only libraries are ok. This bug must be some remnant of the build
system, I don't have gcc installed under /usr/local (neither has the
official Fedora 12).
For example, $SAGE_ROOT/local/lib/libgmpxx.la contains:
dependency_libs=' /home/vbraun/Sage/sage/local/lib/libgmp.la
/usr/local/gcc-4.4.2/x86_64-Linux-core2-fc-binutils-2.20/lib/../lib64/libstdc++.la'
Obviously this is wrong and breaks libtools, if nothing else. If I
download mpir-1.2.2.p0.spkg manually and force re-install it (sage
-f), then libgmpxx.la becomes the correct
dependency_libs=' /home/vbraun/Sage/sage/local/lib/libgmp.la'
Cheers,
Volker
Mariah
I am trying to understand what goes wrong by having the build compiler
in a non-standard place. (I am the sys admin for the particular
build machine in question.) Can you give me an example of
what Sage command or sequence of commands fails?
Mariah
Volker Braun
The problem is that no program can dlink the (C++-using) libraries.
All existing spkgs apparently link statically which works but suffers
from the usual drawbacks. I've tried to modify cddlib to link
dynamically with gmp/mpir:
http://www.stp.dias.ie/~vbraun/cddlib-094f.p3.spkg
Now spkg -i cddlib-094f.p3.spkg fails because of the incorrect
libgmpxx.la
Volker
Mariah
I guess I do not understand that "usual drawbacks" to
statically linking to which you refer. Can you expand, please?
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?
Sorry to be dense. I am just not grasping how you want
to use Sage.
Mariah
Volker Braun
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
Mariah
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
Volker Braun
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
Georg S. Weber
> C-only libraries are ok. This bug must be some remnant of the build
> system, I don't have gcc installed under /usr/local (neither has the
> official Fedora 12).
>
> For example, $SAGE_ROOT/local/lib/libgmpxx.la contains:
>
> dependency_libs=' /home/vbraun/Sage/sage/local/lib/libgmp.la
> /usr/local/gcc-4.4.2/x86_64-Linux-core2-fc-binutils-2.20/lib/../lib64/libstdc++.la'
>
Obviously, the first dependency listed in this file here has been
altered after you installed Sage! But not the second dependency.
I don't have the time to look into this more deeply right now, but I
do assume you've hit a bug in Sage. (Not necessarily in the build
system, but in the part that does the "relocation" stuff after moving
the entire Sage installation tree to another location, as e.g. it is
usually the case when creating a binary distribution and afterwards
installing this one.)
OTOH, the workarounds you propose above are valid (since they do not
seem to trigger the bug).
Thirdly, all the libraries used by Sage should be dynamically linked
--- I consider the cddlib spkg example as another bug, and if I
remember correctly, there already exists a ticket for that.
Cheers,
Georg
Volker Braun
The bug you remembered is http://sagetrac.org/sage_trac/ticket/3304, I
had not seen that report. I'll try to get it fixed now.
Volker
On Jan 27, 2:27 pm, "Georg S. Weber" <georgswe...@googlemail.com>
wrote: