gcc 4.1.2@ubuntu breaks pdftex

Martin Schröder

5 Oct 2007 5 Oct '07

12:52 p.m.

Hi, I (and David) just spend some hours tracking down a compiler bug on Ubuntu 7.04 (gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)): If you compile trunk with build.sh, the resulting binary can not include pdfs (xpdf: reading PDF image failed). If I use my own build.sh, everythings fine. The difference: I set the CFLAGS/CXXFLAGS to -g, while the default is -g -O2. So -O2 breaks pdftex. :-( Best Martin

Show replies by date

Martin Schröder

5 Oct 5 Oct

2:13 p.m.

2007/10/5, Martin Schröder :

...

The difference: I set the CFLAGS/CXXFLAGS to -g, while the default is -g -O2. So -O2 breaks pdftex. :-(

It's not only a problem of gcc 4.1.2. I have the same effect with gcc/g++ (GCC) 4.1.0 (SUSE Linux) :-( Best Martin

Martin Schröder

2:24 p.m.

2007/10/5, Martin Schröder :

...

It's not only a problem of gcc 4.1.2. I have the same effect with gcc/g++ (GCC) 4.1.0 (SUSE Linux) :-(

g++ is the culprit: setting only CXXFLAGS to -g -O2 breaks pdftex. So the cause is likely something in xpdf :-( Best Martin

Taco Hoekwater

3:24 p.m.

Martin Schröder wrote:

...

2007/10/5, Martin Schröder :

...
The difference: I set the CFLAGS/CXXFLAGS to -g, while the default is -g -O2. So -O2 breaks pdftex. :-(

It's not only a problem of gcc 4.1.2. I have the same effect with gcc/g++ (GCC) 4.1.0 (SUSE Linux) :-(

I'll compile pdftex 1.40.5 here. Meanwhile, g++ -v says: Using built-in specs. Target: i586-mandriva-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=i586-mandriva-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp Thread model: posix gcc version 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.1mdv2007.1)

Martin Schröder

3:29 p.m.

2007/10/5, Taco Hoekwater :

...

I'll compile pdftex 1.40.5 here. Meanwhile, g++ -v says:

The effect is (only?) in trunk. I suspect either xpdf 3.02pl1 is difficult or I broke it. Best Martin

Reinhard Kotucha

3:37 p.m.

Martin Schröder writes:

...

2007/10/5, Martin Schröder : It's not only a problem of gcc 4.1.2. I have the same effect with gcc/g++ (GCC) 4.1.0 (SUSE Linux) :-(

Hi Martin, do you remember the problems we had at our last TeX meeting with the Ubuntu machine at the university? I don't remember to which version of gcc we had to downgrade. BTW, I recently failed to compile emacs(+auctex) on a laptop (Ubuntu) of a friend. ./configure claimed that the C compiler is not working. However, I don't have any problems compiling TeXLive or Emacs on my Gentoo system. $ gcc --version gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.1) Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

Martin Schröder

3:45 p.m.

2007/10/5, Reinhard Kotucha :

...

However, I don't have any problems compiling TeXLive or Emacs on my Gentoo system.

Please try pdftex-trunk from svn. Best Martin

Taco Hoekwater

3:56 p.m.

Martin Schröder wrote:

...

2007/10/5, Reinhard Kotucha :

...
However, I don't have any problems compiling TeXLive or Emacs on my Gentoo system.

Please try pdftex-trunk from svn.

Yes, I also have the problem here, with trunk. I've narrowed it down to pdftoepdf.cc: it is fine without -O, and broken with (just -O is enough to trigger the error, no need for -O2) I have to stop here, I don't really know how to debug c++ code. Best wishes, Taco

Martin Schröder

6:37 p.m.

2007/10/5, Taco Hoekwater :

...

I've narrowed it down to pdftoepdf.cc: it is fine without -O, and broken with (just -O is enough to trigger the error, no need for -O2)

Using valgrind I narrowed it down to line 167: p->doc = new p_PDFDoc(docName); With -O line 168 makes valgrind scream: )==26759== Conditional jump or move depends on uninitialised value(s) ==26759== at 0x49DE04: read_pdf_info (pdftoepdf.cc:168) ==26759== by 0x49BF2C: readimage (writeimg.c:295) ==26759== by 0x474841: scanimage (pdftex3.c:3507) ==26759== by 0x478308: doextension (pdftex3.c:4762) ==26759== by 0x47618C: doextension (pdftex3.c:4105) ==26759== by 0x479A7B: maincontrol (pdftex3.c:5738) ==26759== by 0x4170A9: mainbody (pdftexini.c:5752) ==26759== by 0x47FB3B: main (pdftexextra.c:353) So either my C++ foo is not good enough or gcc is simply broken. I suspect the later: -O shouldn't break the code. Best Martin

Taco Hoekwater

6 Oct 6 Oct

2:22 a.m.

Martin Schröder wrote:

...

... or gcc is simply broken. I suspect the later: -O shouldn't break the code.

I agree with that. But you probably have to find a workaround anyway, because those gcc's are already out there and for many people, upgrading gcc is out of the question :(

George N. White III

8:11 a.m.

On 10/6/07, Taco Hoekwater wrote:

...

Martin Schröder wrote:

...
... or gcc is simply broken. I suspect the later: -O shouldn't break the code.

I agree with that. But you probably have to find a workaround anyway, because those gcc's are already out there and for many people, upgrading gcc is out of the question :(

You already have a workaround: different compiler flags for one file. Why not file a bug report against gcc and wait a while to see if clarity emerges? It may be a plain bug in gcc so the code can be left as is and the flags changed until most people have the fixed version, or a case where the optimizer sometimes makes bad choices and you are better off changing the code to circumvent the issue. -- George N. White III Head of St. Margarets Bay, Nova Scotia

Martin Schröder

7 Oct 7 Oct

11:36 p.m.

2007/10/6, George N. White III :

...

Why not file a bug report against gcc and wait a while to see if clarity emerges? It may be a plain bug in gcc so the code can be left as is and the flags changed until most people have the fixed version, or a case where the optimizer sometimes makes bad choices and you are better off changing the code to circumvent the issue.

I did better: I asked the gcc experts for help -- and got it. See http://gcc.gnu.org/ml/gcc-help/2007-10/msg00076.html and the followups. Best Martin

George N. White III

8 Oct 8 Oct

7:48 a.m.

On 10/8/07, Martin Schröder wrote:

...

2007/10/6, George N. White III :

...

...
Why not file a bug report against gcc and wait a while to see if clarity emerges? It may be a plain bug in gcc so the code can be left as is and the flags changed until most people have the fixed version, or a case where the optimizer sometimes makes bad choices and you are better off changing the code to circumvent the issue.

I did better: I asked the gcc experts for help -- and got it. See http://gcc.gnu.org/ml/gcc-help/2007-10/msg00076.html and the followups

Christoph Bartoschek deserves our thanks. I can confirm that building pdftoeps.o with -DDISABLE_OUTLINE fixes the pdf file inclusion error. The problem is quite easy to see once you know where to look -- for the record, the problem is the build system which allowed PDFDoc.h to be compiled with different macro definitions. In a build log, compare the definitions used to build in libs/xpdf/xpdf with those used for pdftoepdf.cc. The #defines in question are set in src/libs/xpdf/xpdf/Makefile.in, so there is no easy way for autoconf in pdftexdir to find them. You could just copy the flags from libs/xpdf/xpdf/Makefile.in to texk/web2c/pdftexdif/Makefile.in or add the corresponding #defines to pdflib.h. Since the latter has to be changed when xpdf changes and the #define is for PDFdoc.h, adding a #define to pdflib.h seems a more logical place, but just copying the flags make differences visible in the build log. It would be helpful for posterity to add comments to pdlib.h where #defines are needed in order to use the xpdf header files. -- George N. White III Head of St. Margarets Bay, Nova Scotia

Reinhard Kotucha

5 Oct 5 Oct

4:57 p.m.

"Martin Schröder" wrote:

...

Please try pdftex-trunk from svn.

I compiled pdftex: $ ./build.sh $ build/texk/web2c/pdftex --version pdfTeX 3.141592-1.50.0-alpha-20070706-2.2 (Web2C 7.5.6) $ svn update $ ./build.sh $ build/texk/web2c/pdftex --version pdfTeX 3.141592-1.50.0-alpha-20070917-2.2 (Web2C 7.5.6) At least it compiles fine, for further tests I have to provide a test environment which doesn't interfere with the TeXLive stuff I have installed. But this will definitely not happen today. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

6126

Age (days ago)

6129

Last active (days ago)

List overview

Download

13 comments

4 participants

participants (4)

George N. White III
Martin Schröder
Reinhard Kotucha
Taco Hoekwater