building libgd must fail if it does not get all of its dependencies

[dimpase]

We get errors like libpng not being linked to libgd, and then oops,
things get broken.

Also, as reported in #31624 comment:28, on fedora-34 C++ ABI issues in optional dependencies of libgd cause trouble.

CC: @enriqueartal

Component: build

Keywords: libgd libpng cygwin macos

Issue created by migration from https://trac.sagemath.org/ticket/27901

[embray]

Changed keywords from none to libgd libpng cygwin macos

[embray]

comment:1

Perhaps purely out of personal interest I'm moving this up to blocker.

[embray]

comment:2

Okay, at least as described this is not the problem I'm having. Upon rebuilding libgd I get the following configuration:

[libgd-2.1.1.1.p1] ** Configuration summary for libgd ..:
[libgd-2.1.1.1.p1]
[libgd-2.1.1.1.p1]    Support for Zlib:                 yes
[libgd-2.1.1.1.p1]    Support for PNG library:          yes
[libgd-2.1.1.1.p1]    Support for JPEG library:         no
[libgd-2.1.1.1.p1]    Support for VPX library:          yes
[libgd-2.1.1.1.p1]    Support for TIFF library:         yes
[libgd-2.1.1.1.p1]    Support for Freetype 2.x library: yes
[libgd-2.1.1.1.p1]    Support for Fontconfig library:   no
[libgd-2.1.1.1.p1]    Support for Xpm library:          no
[libgd-2.1.1.1.p1]    Support for pthreads:             yes

I assume we don't care about JPEG?

[embray]

comment:3

I got curious about what we actually use libgd for in the first place. Apparently it is only used in some little-used(?? I see no use within Sage itself...) to bitmap matrices in Z_2 to a PNG image. Maybe sometimes interesting to look at, but does anyone use this? And is there any reason we explicitly need this library to do it efficiently?

It really looks like the only thing it's used for. Apparently there is also some support for unpickling a matrix from such a PNG image. Weird.

[embray]

comment:4

So in my case I have a libgd that is compiled with PNG support, and linked against the libpng16 in Sage, at least presumably, and it still fails to load.

If, out of curiosity, I manually comment out all the parts of matrix_mod2_dense.pyx that use libgd, and remove its requirement from the link flags for that module, it imports fine. So there is definitely something about the libgd requirement that is blowing up, but I can't figure out easily what it is for some reason.

I'm trying now with rebuilding libpng (and in turn all its dependents of which there are many) in the off chance that can tell me anything...

[embray]

comment:5

Still having some very bizarre problems related to loading matrix_mod2_dense.dll, and in turn cyggd-3.dll. I can't make heads or tails out of it. I've tried going back to older versions, even back to 8.7 final (which always worked) I'm still getting the problem.

I even hypothesized whether it was a problem with using some of the system libraries for xz, bz2, or more likely zlib, but even disabling those (and building them in Sage) didn't make the problem go away.

Meanwhile, I have a build of Sage in another directory where I experimented with using the system libgd (#27825) and it works! No problem.

At the very least that's a point in favor of moving forward on #27825. But this is still very fishy and I need to get to the bottom of it. It turns out I will likely need to use WinDBG to have any hope of seeing what's going wrong here.

[embray]

comment:6

The Cygwin problem I was discussing here is fixed by #27970, ironically due to libgd using too many (more than necessary) of its possible dependencies.

[embray]

comment:7

Moving open critical and blocker issues to the next release milestone (optimistically).

[vbraun]

comment:8

Any progress here? This doesn't seem to be affecting a lot of users, I don't think it should be a blocker. But if a fix materializes real soon then I'm open to merging it...

[embray]

comment:10

We should check, somehow, (in the spkg-build/spkg-install for libgd?) that it properly detected and built with libpng support. Other than PNG I don't think we care about any of the other dependencies.

[dimpase]

comment:11

hmm, do you mean "check in spkg-configure.m4 of libgd"?

[vbraun]

comment:14

Workaround for the

[...]
/usr/bin/ld: /usr/lib64/libvmaf.so.0: undefined reference to `std::__throw_bad_array_new_length()@GLIBCXX_3.4.29'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:831: gdcmpgif] Error 1
make[2]: Leaving directory '/home/release/Sage/local/var/tmp/sage/build/libgd-2.3.2/src/src'
make[1]: *** [Makefile:644: all] Error 2
make[1]: Leaving directory '/home/release/Sage/local/var/tmp/sage/build/libgd-2.3.2/src/src'
make: *** [Makefile:426: all-recursive] Error 1
********************************************************************************************************************************************************************
Error building libgd-2.3.2
********************************************************************************************************************************************************************

on Fedora 34 is to set

LIBGD_CONFIGURE=--without-avif

[enriqueartal]

comment:15

Confirmed, sage 9.4.beta0 compiles with that option. I declared it using export LIBGD_CONFIGURE=--without-avif

[vbraun]

comment:16

I've made a patch at #31879