Sage depends on (system) libvpx?!

[Luca De Feo]

After a system upgrade my built-from-source sage install started
crashing with the log message

ImportError: libvpx.so.3: cannot open shared object file: No such
file or directory

and indeed my system update updated libvpx from 3.x to 4.x, while I
can't find any trace of it in the sage/ folder. By way of find-ing and
grep-ing, I could however find this

$ ldd local/lib/libgd.so
...
libvpx.so.3 => not found
...

I reinstalled libgd with `sage -i -f`, and everything went back to
normal (well, hopefully: tests pass, but I have no idea what libgd is
used for).

ldd shows another couple of non-basic system libraries libgd depends
upon. Among them: libtiff and libjpeg. Here's the full output:

$ ldd local/lib/libgd.so
linux-vdso.so.1 (0x00007ffc20bd8000)
libz.so.1 => /home/defeo/sage/local/lib/libz.so.1 (0x00007fe4e635e000)
libpng12.so.0 => /home/defeo/sage/local/lib/libpng12.so.0
(0x00007fe4e6139000)
libfreetype.so.6 =>
/home/defeo/sage/local/lib/libfreetype.so.6 (0x00007fe4e5e9d000)
libvpx.so.4 => /usr/lib/libvpx.so.4 (0x00007fe4e591d000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fe4e5619000)
libtiff.so.5 => /usr/lib/libtiff.so.5 (0x00007fe4e5395000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fe4e4ff5000)
libbz2.so.1 => /home/defeo/sage/local/lib/libbz2.so.1
(0x00007fe4e4de5000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe4e4bc8000)
/usr/lib64/ld-linux-x86-64.so.2 (0x0000561dc5624000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007fe4e49a2000)
libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007fe4e4738000)

Comparing with an install on a different machine, I see no system
library libgd depends on there. My guess is that those are optional
dependencies that libgd grabs at configure time. Is this behaviour
intended, or should we add a couple more --without to the install
script?

Luca

[Jean-Pierre Flori]

I would say that we should explicitly state what we want  and don't want to link to, so add without-* flags especially for binary dists.

But if we want to migrate to using system libs why not let gd use whatever it wants!

[Luca De Feo]

> But if we want to migrate to using system libs why not let gd use whatever it wants!

Well, in that case we should use system gd, shouldn't we?

[Jean-Pierre Flori]

On Tuesday, August 16, 2016 at 5:29:52 PM UTC+2, Luca De Feo wrote:

> But if we want to migrate to using system libs why not let gd use whatever it wants!

Well, in that case we should use system gd, shouldn't we?

Yes indeed.
And if we don't use the system one and build our own, let's just prevent the built one to use whatever it wants from the system.

[leif]

We shouldn't do that for all optional libs libgd might find and use
(unless we're building a bdist).

There's some quite old ticket on trac (I guess still open) regarding at
least libjpeg and libtiff.

AFAIK libgd has recently been upgraded, so it's quite possible also the
behaviour (or what's used in Sage and what not) now changed.

Incidentally, we also had an issue with an incompatible libvpx (breaking
the build) a while ago...


-leif

[Nicolas M. Thiery]

Just to leave a trace in case someone would hit the same issue: I just
upgraded from Ubuntu 16.4 to 17.4, and my sage (built from source)
would not start afterward:

from sage.matrix.matrix_space import MatrixSpace
File "/opt/sage-git2/local/lib/python2.7/site-packages/sage/matrix/matrix_space.py", line 48, in <module>
from . import matrix_modn_sparse
File "sage/matrix/matrix_integer_dense.pxd", line 10, in init sage.matrix.matrix_modn_sparse
cdef class Matrix_integer_dense(Matrix_dense):
File "sage/matrix/matrix_mod2_dense.pxd", line 4, in init sage.matrix.matrix_integer_dense
cdef class Matrix_mod2_dense(Matrix_dense):

ImportError: libvpx.so.3: cannot open shared object file: No such file or directory

Rebuilding Sage's libgd package fixed that:

sage -i -f libgd

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/