Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 374147 - >=app-text/texlive-2010: pdflatex and pdfetex don't default to PDF output
Summary: >=app-text/texlive-2010: pdflatex and pdfetex don't default to PDF output
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Andrey Grozin
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 374645
  Show dependency tree
 
Reported: 2011-07-05 15:51 UTC by Martin von Gagern
Modified: 2011-07-30 20:58 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Proposed fix (gentoo374147a.patch,1.37 KB, patch)
2011-07-29 14:51 UTC, Martin von Gagern
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2011-07-05 15:51:24 UTC
$ cat <<EOF>test.asy 
size(10cm, 0);
draw(unitcircle);
label("foo", (0, 0), S);
EOF
$ asy -keep -tex pdflatex test.asy
[...]
! LaTeX Error: Cannot determine size of graphic in test_0.pdf (no BoundingBox).
[...]
/usr/share/asymptote/plain_shipout.asy: 82.10: runtime: shipout failed

Packages likely relevant for this issue:
media-gfx/asymptote-2.13
dev-texlive/texlive-latex-2010
app-text/texlive-2010-r2
app-text/texlive-core-2010-r2

The -keep is only to help debugging; it doesn't cause this bug.

The error message appears as if someone tried to read that file as EPS while it is in fact PDF. OK, so let's change it in such a way that it forces the use of PDF. Then we get an even stranger error message:

$ sed 's:\\usepackage{graphicx}:\\usepackage[pdftex]{graphicx}:' \
  test_.tex > test2.tex
$ pdflatex '\scrollmode\input test2.tex'
[...]
(/usr/share/texmf-dist/tex/latex/pdftex-def/pdftex.def

! Package pdftex.def Error: PDF mode expected, but DVI mode detected!
(pdftex.def)                If you are using `latex', then call `pdflatex'.
(pdftex.def)                Otherwise check and correct the driver options.
(pdftex.def)                Error recovery by switching to PDF mode.
[...]

So it appears as if pdflatex no longer sets its pdfoutput variable.
None of the following commands did help:
# dispatch-conf
# texmf-update
# emerge -1 dev-texlive/texlive-latex
# fmtutil-sys --all
# emerge -1 $(eix -I --only-names texlive)
Comment 1 Martin von Gagern 2011-07-05 17:20:10 UTC
I've found a possible workaround:

# cat <<EOF> /usr/local/bin/pdflatex
#!/bin/sh
# Work around https://bugs.gentoo.org/374147
exec /usr/bin/pdflatex -output-format=pdf "$@"
EOF
# chmod a+x /usr/local/bin/pdflatex

This will install a wrapper which supplies the -output-format argument to the pdflatex version installed by portage. At least the asy stuff works this way.
Comment 2 Martin von Gagern 2011-07-10 13:42:59 UTC
Cross reference: bug #374645 indicates that there is something seriously wrong with the PDF-generating parts of my TeX setup.
Comment 3 Martin von Gagern 2011-07-29 12:44:39 UTC
Changing Summary to reflect the broader problem of pdflatex not defaulting to pdf output. As pdfetex is affected as well (as per bug #374645), this probably isn't specific to the texlive-latex package, so I now refer to the texlive meta package.

Original Summary was:
"media-gfx/asymptote-2.13 and dev-texlive/texlive-latex-2010:
 LaTeX Error: Cannot determine size of graphic in *.pdf (no BoundingBox)."

Just updated texlive to its 2011 release, and the problem persists. I did merge config files and run texmf-update as the texlive-core ebuild requests. The steps given in comment #0 still result in an error. As a quicker test, based on ideas from bug #374645 comment #4, is this:

$ /usr/bin/pdflatex '\scrollmode\showthe\pdfoutput\stop'
This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2011)
 restricted \write18 enabled.
entering extended mode
LaTeX2e <2009/09/24>
Babel <v3.8l> and hyphenation patterns for english, dumylang, nohyphenation, uk
english, usenglishmax, german-x-2009-06-19, ngerman-x-2009-06-19, german, ngerm
an, swissgerman, ancientgreek, ibycus, greek, monogreek, loaded.

> 0.
<*> \scrollmode\showthe\pdfoutput
                                 \stop
(see the transcript file for additional information)
No pages of output.
Transcript written on texput.log.

I believe that a correct setup should print "1." instead of "0." there. The workaround from comment #2 gives a value of "2.".
Comment 4 Martin von Gagern 2011-07-29 14:51:55 UTC
Created attachment 281463 [details, diff]
Proposed fix

OK, this appears to be a buffer overflow thingy.

$ gdb --args /usr/bin/pdflatex '\scrollmode\showthe\pdfoutput\stop'
(gdb) watch pdfoutputoption
Watchpoint 1: pdfoutputoption
(gdb) run
Starting program: /usr/bin/pdflatex \\scrollmode\\showthe\\pdfoutput\\stop
[Thread debugging using libthread_db enabled]
Hardware watchpoint 1: pdfoutputoption

Old value = 0
New value = -268435455
0x000000000040994a in initialize () at pdftexini.c:119
119         mubytecswrite [i ]= -268435455L ;

So as you can see, the pdfoutputoption variable is assigned to in a line of source code which doesn't even mention that name.

Closer analysis shows it to be an off-by-one error. Tracing this up the chain, all named files are in texlive-20110705-source/texk/web2c:

texd.h:100:EXTERN halfword mubytecswrite[128]  ;
pdftexini.c:118:  {register integer for_end; i = 0 ;for_end = 128 ;
                  if ( i <= for_end) do 
pdftexini.c:119:    mubytecswrite [i ]= -268435455L ;
pdftexini.c:120:  while ( i++ < for_end ) ;} 

pdftex.p:55:mubytecswrite:array[0..127]of halfword;mubyteskip:integer;
pdftex.p:357:for i:=0 to 128 do mubytecswrite[i]:=-268435455;mubytekeep:=0;

All of the above files are generated, though. Took me some time to identify the actual source that was generated from. It appears there are two, one in enctex and the other in xetex.

texk/web2c/enctex.ch:14:mubyte_cswrite: array [0..127] of pointer;
texk/web2c/enctex.ch:45:for i:=0 to 128 do mubyte_cswrite[i]:=null;
texk/web2c/xetexdir/xetex.ch:197 and 331 the same

The correct fix is changing the upper limit for the loop counter to 127, as the indices are taken modulo 128, so that 128 itself will never occur as a value. The attached patch does include that fix. Until it makes it into portage, the usual "ebuild prepare, patch, ebuild merge" sequence can be used to apply it to a single build. Unfortunately the texlive-core ebuild doesn't support user patches in /etc/portage/patches via the epatch_user function from eutils.eclass, so it isn't enough to drop the patch into a specific directory.

By the way, I noticed that texlive-core apparently compiles its own copy of ICU. Has anyone tried using the dev-libs/icu package instead?
Comment 5 Martin von Gagern 2011-07-29 15:12:11 UTC
Upstream has already fixed the issue in their svn a few days ago:
http://tug.org/svn/texlive/trunk/Build/source/texk/web2c/enctex.ch?r1=23186&r2=23187
http://tug.org/svn/texlive/trunk/Build/source/texk/web2c/xetexdir/xetex.ch?r1=22123&r2=23187
So there should be no need to file an upstream bug report for this.
Comment 6 Martin von Gagern 2011-07-29 16:13:40 UTC
It appears that the bug has been present in the sources for a LONG time: texk/web2c/tex.ch had it since that file was added to svn in 2006. Apparently it only recently started to manifest itself in this way. Might be due to the way a specific combination of compiler, linker and flags does its variable layout. In any case, as the code is so obviously broken, the fix so obviously harmlas, and as this also affects package builds like bug 374645, I propose including the fix not only in a revbump for texlive-core-2011, but also backport it to suitable revbumps of past texlive releases, the stable 2008 version in particular.
Comment 7 Alexis Ballier gentoo-dev 2011-07-30 20:58:56 UTC
fixed in 2011-r1 and 2010-r4, thanks!