Opened 4 years ago

Last modified 2 months ago

#27901 new defect

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

Reported by: Dima Pasechnik Owned by:
Priority: major Milestone: sage-9.8
Component: build Keywords: libgd libpng cygwin macos
Cc: Enrique Artal Bartolo Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by Matthias Köppe)

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

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

Change History (20)

comment:1 Changed 4 years ago by Erik Bray

Keywords: libgd libpng cygwin macos added
Priority: criticalblocker

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

comment:2 Changed 4 years ago by Erik Bray

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

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

I assume we don't care about JPEG?

comment:3 Changed 4 years ago by Erik Bray

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.

comment:4 Changed 4 years ago by Erik Bray

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...

Last edited 4 years ago by Erik Bray (previous) (diff)

comment:5 Changed 3 years ago by Erik Bray

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.

comment:6 Changed 3 years ago by Erik Bray

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.

comment:7 Changed 3 years ago by Erik Bray

Milestone: sage-8.8sage-8.9

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

comment:8 Changed 3 years ago by Volker Braun

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...

comment:9 Changed 3 years ago by Dima Pasechnik

Milestone: sage-8.9sage-wishlist
Priority: blockermajor

comment:10 Changed 3 years ago by Erik Bray

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.

comment:11 Changed 3 years ago by Dima Pasechnik

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

comment:12 Changed 18 months ago by Matthias Köppe

Milestone: sage-wishlistsage-9.4

comment:13 Changed 18 months ago by Matthias Köppe

Cc: Enrique Artal Bartolo added
Description: modified (diff)

comment:14 Changed 18 months ago by Volker Braun

Workaround for the

/usr/bin/ld: /usr/lib64/ 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


comment:15 Changed 18 months ago by Enrique Artal Bartolo

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

comment:16 Changed 18 months ago by Volker Braun

I've made a patch at #31879

comment:17 Changed 16 months ago by Matthias Köppe

Milestone: sage-9.4sage-9.5

comment:18 Changed 12 months ago by Matthias Köppe

Milestone: sage-9.5sage-9.6

comment:19 Changed 7 months ago by Matthias Köppe

Milestone: sage-9.6sage-9.7

comment:20 Changed 2 months ago by Matthias Köppe

Milestone: sage-9.7sage-9.8
Note: See TracTickets for help on using tickets.