latest poppler prevents pdftex/pdflatex from working correctly

Thank you for your bug report, could you add an example to the bug? opening pdf works fine there I guess that pdflatex are a special format?

can't attach more then one file together, but attaching a test latex file and a pdf to be included

put them both in the same dir and pdflatex test.tex

from an ltrace of pdflatex w/ bad poppler lib

_Znwj(284, 0x1a787d, 0, 0x28bff4, 0x28bff4) = 0x9298cd0
_ZN12GlobalParamsC1EPKc(0x9298cd0, 0, 0, 0x28bff4, 0x28bff4) = 0x28d3a0
_ZN12GlobalParams11setErrQuietEi(0x9298cd0, 0, 0, 0x28bff4, 0x28bff4) = 0
_Znwj(24, 0, 0, 0x28bff4, 0x28bff4) = 0x92a5c60
xstrdup(0x9295e80, 0, 0, 0x28bff4, 0x28bff4) = 0x92a5c28
_Znwj(32, 0, 0, 0x28bff4, 0x28bff4) = 0x92a5c38
_ZN9GooStringC1EPKc(0x92a5c38, 0x92a5c28, 0, 0x28bff4, 0x28bff4) = 0x92a5c38
_Znwj(48, 0x92a5c28, 0, 0x28bff4, 0x28bff4) = 0x92a5c80
_ZN6PDFDocC1EP9GooStringS1_S1_Pv(0x92a5c80, 0x92a5c38, 0, 0, 0) = 1
_ZN4XRef9okToPrintEi(0x92a5f60, 0, 0, 0, 0) = 1

and with good poppler lib

_Znwj(284, 0x4a887d, 0, 0x58cff4, 0x58cff4) = 0x993bc88
_ZN12GlobalParamsC1EPKc(0x993bc88, 0, 0, 0x58cff4, 0x58cff4) = 0x58e3a0
_ZN12GlobalParams11setErrQuietEi(0x993bc88, 0, 0, 0x58cff4, 0x58cff4) = 0
_Znwj(24, 0, 0, 0x58cff4, 0x58cff4) = 0x9948c80
xstrdup(0x9938e38, 0, 0, 0x58cff4, 0x58cff4) = 0x9948bf0
_Znwj(32, 0, 0, 0x58cff4, 0x58cff4) = 0x9948bc8
_ZN9GooStringC1EPKc(0x9948bc8, 0x9948bf0, 0, 0x58cff4, 0x58cff4) = 0x9948bc8
_Znwj(48, 0x9948bf0, 0, 0x58cff4, 0x58cff4) = 0x9948ca0
_ZN6PDFDocC1EP9GooStringS1_S1_Pv(0x9948ca0, 0x9948bc8, 0, 0, 0) = 1
_ZN4XRef9okToPrintEi(0x9948f80, 0, 0, 0, 0) = 1

nothing obviously different to me (i.e. function failing or something).

the example there opens fine on my karmic, what architecture do you use?

I can confirm this issue running Kubuntu Karmic with libpoppler 0.11.2. Im running a 64bit machine. The example above and my own documents work fine on a 32bit Jaunty installation (libpoppler 0.10.5-ubuntu2.2).

@Sebastian: Of course those examples open fine, there is nothing wrong with them. pdflatex fails to translate the tex-file with the error message mentioned in the initial report.

I can confirm this as well (on a 32bit install). It affects pdfcrop as well, also included in texlive.

I grabbed poppler 0.11.1 from http://poppler.freedesktop.org/ and compiled it using the debian directory of the 0.11.2 package.
Beside a problem with a missing html documentation, the build went fine but the problem is still here.

Doing the same with 0.11.0 fixed the problem for me as well.
Just like pdftex, pdfcrop works again with 0.11.0 (but not with 0.11.1).

Confirmed on a 64 bit up-to-date karmic install. PdfTex and PdfLatex all fail, and on a parallel Jaunty install (64 bit too) they work fine. Noticed this when using Kile

short version: fixed for me

long version: my system was working with self-made packages of poppler 0.11.0 and the same behaviour appeared (I guess) after the latest texlive update.
It is now working fine again with the poppler version available in the archive but not with the older version!

The mandriva bugzilla is not available right now si I can't check in it, but what is the reason for this strict version dependancy ?
Did poppler break the ABI ? will the next versions be OK should we to expect such breakage again ?

fixed for me, too.

Mandriva solved it recompiling texlive, so yes, the ABI breakage might have been solved by latest texlive's uploads.