Opened 10 years ago

Closed 20 months ago

dvipng fails due to missing jpeg symbols (gd spkg)

Reported by: Owned by: mjo jdemeyer critical sage-duplicate/invalid/wontfix packages: standard N/A

Description

On machines where the system gd is build with jpeg support, dvipng will fail with missing symbols:

WARNING: display latex u'10^8': dvipng exited with error:
[stderr]
dvipng: symbol lookup error: dvipng: undefined symbol:
gdImageCreateFromJpegPtr


because sage's gd is built without jpeg support.

This breaks pretty much all of the reference documentation.

Some potential solutions:

• Remove the --without-jpeg flag from the gd spkg
• Package dvipng with sage, and build it against sage's gd
• Don't hide the system gd if it's present while building the docs

comment:1 Changed 8 years ago by mjo

• Priority changed from major to critical

The docs now default to using MathJax?, which fixes that problem, but we're traded it for a worse one: I can no longer plot anything.

With a fresh sage-5.10.rc2:

sage: plot(sin,x,-1,1)
dvipng: symbol lookup error: dvipng: undefined symbol: gdImageCreateFromJpegPtr
...
RuntimeError: dvipng was not able to process the following file:
/home/mjo/.sage//matplotlib-1.2.1/tex.cache/c97c52e62b093248234a0445c488a218.dvi
Here is the full report generated by dvipng:



The error only occurs within sage; if I run dvipng manually (not within sage -sh), it works fine. If I run it within sage -sh, it crashes with the missing symbols error.

The problem is the same as the original report. You can't expect my dvipng to be built against a gd with the same flags as the one shipped by sage.

comment:2 Changed 8 years ago by mjo

This only occurs when you use latex for the text in the plot. I do that in my init.sage, so to reproduce,

sage --nodotsage

sage: from matplotlib import rcParams
sage: rcParams['text.usetex'] = True
sage: plot(sin,x,-1,1)
<boom>


See #13543 for why you might want to use a real latex implementation.

comment:3 in reply to: ↑ description ; follow-up: ↓ 4 Changed 8 years ago by leif

Some potential solutions:

• Remove the --without-jpeg flag from the gd spkg
• Package dvipng with sage, and build it against sage's gd
• Don't hide the system gd if it's present while building the docs
• Install the optional (currently outdated I guess) jpeg spkg.
• Make sure dvipng isn't called with Sage's environment set up (LD_LIBRARY_PATH; use sage-native-execute or whatever).
• Local fix: Set RUN_PATH in the dvipng executable... ;-)

comment:4 in reply to: ↑ 3 ; follow-ups: ↓ 7 ↓ 8 Changed 8 years ago by leif

• Make sure dvipng isn't called with Sage's environment set up (LD_LIBRARY_PATH; use sage-native-execute or whatever).

E.g. create a wrapper script $SAGE_LOCAL/bin/dvipng that calls sage-native-execute dvipng "$@".

comment:5 follow-up: ↓ 6 Changed 8 years ago by vbraun

Please not yet another wrapper script, any external (non-Sage) binaries must be called via sage-native-execute. Including dvipng.

comment:6 in reply to: ↑ 5 Changed 8 years ago by mjo

Please not yet another wrapper script, any external (non-Sage) binaries must be called via sage-native-execute. Including dvipng.

So this should be fixed in matplotlib or whoever is calling dvipng? The wrapper script would seem to do that without having to patch every caller of dvipng, but I understand not wanting a wrapper script for every binary we use.

comment:7 in reply to: ↑ 4 Changed 8 years ago by leif

• Make sure dvipng isn't called with Sage's environment set up (LD_LIBRARY_PATH; use sage-native-execute or whatever).

E.g. create a wrapper script $SAGE_LOCAL/bin/dvipng that calls sage-native-execute dvipng "$@".

That was rather meant as an ad-hoc solution for Michael, not that we should ship such a script (although it might turn out to be the easiest solution ;-) ).

(Just like messing with the system's(!) dvipng's DT_RUNPATH.)

comment:8 in reply to: ↑ 4 ; follow-up: ↓ 10 Changed 8 years ago by mjo

• Make sure dvipng isn't called with Sage's environment set up (LD_LIBRARY_PATH; use sage-native-execute or whatever).

E.g. create a wrapper script $SAGE_LOCAL/bin/dvipng that calls sage-native-execute dvipng "$@".

Interestingly enough, the wrapper script eats up 100% CPU and never terminates.

comment:9 Changed 8 years ago by vbraun

Just to point out the obvious, a script called dvipng must exclude itself from the path before calling dvipng lest you get an infinite recursion.

comment:10 in reply to: ↑ 8 Changed 8 years ago by leif

• Make sure dvipng isn't called with Sage's environment set up (LD_LIBRARY_PATH; use sage-native-execute or whatever).

E.g. create a wrapper script $SAGE_LOCAL/bin/dvipng that calls sage-native-execute dvipng "$@".

Interestingly enough, the wrapper script eats up 100% CPU and never terminates.

That's because sage-native-execute does not yet restore the original PATH.

comment:11 Changed 8 years ago by jdemeyer

• Milestone changed from sage-5.11 to sage-5.12

comment:12 Changed 8 years ago by vbraun_spam

• Milestone changed from sage-6.1 to sage-6.2

comment:13 Changed 7 years ago by vbraun_spam

• Milestone changed from sage-6.2 to sage-6.3

comment:14 Changed 7 years ago by vbraun_spam

• Milestone changed from sage-6.3 to sage-6.4

comment:15 Changed 6 years ago by jdemeyer

• Component changed from build to packages: standard
• Owner changed from GeorgSWeber to jdemeyer

comment:16 Changed 21 months ago by mjo

• Milestone changed from sage-6.4 to sage-duplicate/invalid/wontfix
• Status changed from new to needs_review

This is solved to a degree, because the top-level configure script can detect and use the system copy of libgd, which will have whatever symbols the system copy of dvipng needs.

comment:17 Changed 21 months ago by mjo

• Status changed from needs_review to positive_review

comment:18 Changed 20 months ago by chapoton

• Resolution set to invalid
• Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.