Summary: | dev-tex/luatex-0.70.1 fails to compile with app-text/poppler-0.18.0 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Cédric Jeanneret <contact> |
Component: | [OLD] Development | Assignee: | TeX project <tex> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aidecoe, andriy155, andrzej.kardas, ankh_symbool, ansla80, b.brachaczek, bambucha14, bertrand, carlphilippreh, casual.dodo, contact, cruzki123, deduktionstheorem, dschridde+gentoobugs, edt, fcoiffie, fkrogh, fordfrog, gentoo-bugs, gentoo, georgi, giuseppe, grozin, halcy0n, hsggebhardt, I.zaufi, jason, marco1475, mark_alec, Martin.Jansa, Martin.vGagern, matrix47, moriramar, nbkolchin, nbowler, ooblick, optiluca, pcmoore, plaes, polidevk.polidevk, proteuss, pva, realnc, renegabriels, rktspm, rose, simon.kohlmeyer, skrattaren, sleeperseven, spatz, staff, tetromino, ulm, vityokster, vivo75, wtt6, z23, zeekec |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 384885 | ||
Attachments: |
build.log
Drop LUA bindings for removed poppler API Drop LUA bindings for removed poppler API gentoo384875b.patch Ebuild folder for overlay Another patch that uses the version macros from poppler/glib/poppler-features.h Patch to be applied conditionally |
Description
Cédric Jeanneret
2011-09-29 05:53:00 UTC
Created attachment 288187 [details]
build.log
Fails due to the poppler update, apparently it is not compatible with poppler-0.18.0 Same problem here. Downgrading poppler allows it to build again. This is the poppler commit that made the dtor protected: http://cgit.freedesktop.org/poppler/poppler/commit/poppler/Annot.h?id=664865a2ddca9c20ac36a41aef52ebf12eab838d I can confirm the exact same issue on my ~amd64 laptop. Any workarounds besides downgrading poppler? When I try to mask 0.18.0 the next version in the tree is version 0.16.7 which fails to build on my system. Any help would be appreciated (In reply to comment #5) > I can confirm the exact same issue on my ~amd64 laptop. Any workarounds besides > downgrading poppler? When I try to mask 0.18.0 the next version in the tree is > version 0.16.7 which fails to build on my system. Put the patch from bug 384789 in /etc/portage/patches/app-text/poppler and add this in /etc/portage/bashrc post_src_unpack() { cd "${S}" epatch_user } Then emerge poppler-0.16.7. You can undo the above again after building. I keep it though so I can apply patches like this to other ebuilds too. (In reply to comment #6) > (In reply to comment #5) > > I can confirm the exact same issue on my ~amd64 laptop. Any workarounds besides > > downgrading poppler? When I try to mask 0.18.0 the next version in the tree is > > version 0.16.7 which fails to build on my system. > > Put the patch from bug 384789 in /etc/portage/patches/app-text/poppler and add > this in /etc/portage/bashrc > > post_src_unpack() { > cd "${S}" > epatch_user > } > > Then emerge poppler-0.16.7. You can undo the above again after building. I > keep it though so I can apply patches like this to other ebuilds too. Confirm. The problem exist in my system too and I add to mask 0.18.0 and apply the patch from bug 384789. Confirmed on x86. Downgrading to stable poppler solve problem Upstream is aware of this issue. However, they only support the version of Poppler they bundle with the distribution. So this will be fixed when they bundle a new version: http://article.gmane.org/gmane.comp.tex.luatex/2603 This is a problem I hit too. Does anyone have a patch to try to get it to build against the new poppler now? Created attachment 288363 [details, diff] Drop LUA bindings for removed poppler API This patch makes luatex compile for me. ‘virtual Annot::~Annot()’ is protected (since 0.17.0) http://cgit.freedesktop.org/poppler/poppler/commit/?id=664865a2ddca9c20 Replace "delete (Annot *)foo" with "((Annot *)foo)->decRefCnt()" ‘AnnotBorderStyle’ was not declared (since 0.17.0) http://cgit.freedesktop.org/poppler/poppler/commit/?id=2bf82f27bd9c8f97 http://cgit.freedesktop.org/poppler/poppler/commit/?id=fa0bb5bbea5bf276 Seems like AnnotBorderStyle was somehow replaced by AnnotBorder. That change was back in poppler 0.10.0, only the cleanup was later in 0.17.0. ‘EmbFile’ was not declared (since 0.17.2) http://cgit.freedesktop.org/poppler/poppler/commit/?id=04dfb2c984b3c994 Apparently EmbFile was replaced by FileSpec, but most methods are different. The first fix is easy, but the other two require a decision. We could either try to maintain the LUA API even as poppler broke its C API. That would ensure that lua scripts making use of this code were to remain functional. But it would also mean writing a heavy compatibility layer, and deliberately diverging from poppler upstream. The other choice would be dropping the removed API from the LUA interface as well. This would be a deliberate divergence from luatex upstream and their bundled poppler. There might be scripts out there relying on that poppler API, and they woudln't work with Gentoo luatex, at least not if that was compiled against recent poppler. I guess the number of such scripts should be pretty rare, though. So the attached patch follows this route. I see little point in making new API (FileSpec in particular) available in luatex on Gentoo before luatex upstream does so. It's unlikely people will be writing code to use that API before. If someone needs it nevertheless, he'd have to come up with a patch to address this. By the way, can someone who still has poppler 0.16 around please give this patch a try, to see whether that compiles as well? It should contain suitable ifdefs, but it would be better to know for sure, particularly to verify that the poppler/cpp/poppler-version.h header is found by the preprocessor. Created attachment 288369 [details, diff]
Drop LUA bindings for removed poppler API
Had a stray reference to FileSpec in the part used by old poppler.
(In reply to comment #11) > That change was back in poppler 0.10.0, only the cleanup was later in 0.17.0. Change was even 0.7.0; git tag sorts its output alphabetically, not numerically. Just a note that the patch from post #13 makes luatex-0.70.1 compilable with poppler-0.18.0. The patch form #13 works for me too. Created attachment 288457 [details]
gentoo384875b.patch
Had a problem downloading this patch. For simplicity sake I have reuploaded and named the patch to this bug. Patch indeed works and allows luatex to emerge. Thanks.
Created attachment 288459 [details]
Ebuild folder for overlay
Just drop this into an overlay and it works.
Can confirm the patch works on ~x86. Any chance of rolling this up into an -r1 release any time soon? :-) (In reply to comment #19) > Any chance of rolling this up into an -r1 release any time soon? :-) It's a compile-time issue, so there is no need to bump the revision for this. Sorry, my upload of the same patch was unnecessary. Please use earlier patch (In reply to comment #9) > Upstream is aware of this issue. (In reply to comment #13) > Created attachment 288369 [details, diff] > Drop LUA bindings for removed poppler API Sent them my patch, to deal with as they see fit: http://thread.gmane.org/gmane.comp.tex.luatex/2630 Gentoo should definitely fix this at the distro level, even if upstream does not, as it is Gentoo who decided (righhtly so) not to use the bundled poppler. Thanks for the patch. Worked perfectly on my ~amd64 based systems. Created attachment 288741 [details, diff]
Another patch that uses the version macros from poppler/glib/poppler-features.h
The patch by Martin requires the C++ API of poppler which is not needed by luatex (poppler[cxx]), so the compile process failed for me. There is another set of version macros in <poppler/glib/poppler-features.h>, which are spelled differently. I don't know by which useflag this header is enabled (presumably by xpdf-headers, which luatex already needs). In any case, I made a different patch that uses these version macros instead. > (In reply to comment #19)
> > Any chance of rolling this up into an -r1 release any time soon? :-)
>
> It's a compile-time issue, so there is no need to bump the revision for this.
> (In reply to comment #20)
please do a rev-bump when patch is ready, even if it's a compile time issue, this way it will be caught by an `emerge -uD world` even if we forget about this bug and don't run revdep-rebuild for some time.
TIA
(In reply to comment #26) > please do a rev-bump when patch is ready, even if it's a compile time issue, Martin means that there's no need in bumping revision, since there's no need to recompile luatex for those who have it installed and working. And issues with revdep-rebuilding or first installation (like this) would be remedied by new ebuild with old name. (In reply to comment #27) > (In reply to comment #26) > > please do a rev-bump when patch is ready, even if it's a compile time issue, > Martin means that there's no need in bumping revision, since there's no need > to recompile luatex for those who have it installed and working. And issues > with revdep-rebuilding or first installation (like this) would be remedied by > new ebuild with old name. I've it installed and not working, ldd show missing libpoppler.so.13, while revdep-rebuild will rebuild luatex I'm updating more often than revdep-rebuilding, thus my request. While it's totally correct not to revbump if the package never builded for some systems (it will be caught also by an update), in this case it got broken after the first install and it's a cheap to build package involving many users so the developers may find useful to clean any doubt and forcing a rebuild for everybody. just my 0.02€ (In reply to comment #25) > The patch by Martin requires the C++ API of poppler which is not needed by > luatex (poppler[cxx]), so the compile process failed for me. > There is another set of version macros in <poppler/glib/poppler-features.h>, > which are spelled differently. > I don't know by which useflag this header is enabled (presumably by > xpdf-headers, which luatex already needs). > In any case, I made a different patch that uses these version macros instead. Those headers are pulled in by poppler[cairo]. Is there any other way to go about this that doesn't force either of those features on for poppler? (I don't know much about this package, but am willing to proxy the appropriate patch to fix this) (In reply to comment #29) > Is there any other way to go > about this that doesn't force either of those features on for poppler? Poppler apparently doesn't unconditionally install any header file giving its version number. So I'd consider these approaches: 1. Remove #ifdefs from the patch, and apply it conditionally, based on the result of has_version. 2. Patch configure to read "pkg-config --modversion poppler" and define a suitable macro there. 3. Patch configure to perform a suitable feature test. 1. is easiest for Gentoo, although it's not an option for upstream. (In reply to comment #22) > Sent them my patch, to deal with as they see fit: > http://thread.gmane.org/gmane.comp.tex.luatex/2630 Hartmut Henkel replied to that: "Seems it's still not too late just to remove these few (non-essential) api functions, unconditionally." So we might consider doing the same. Still leaves the change drom delete to decRefCnt, though, so we still have to make a decision based on poppler version. Created attachment 288823 [details, diff]
Patch to be applied conditionally
This patch does the modifications required for poppler 0.18.0 without checking any preprocessor macros. It should be applied conditionally, i.e.
has_version '>=app-text/poppler-0.18.0:0' && epatch "${FILESDIR}/this.patch"
(In reply to comment #31) > Created attachment 288823 [details, diff] > Patch to be applied conditionally > > This patch does the modifications required for poppler 0.18.0 without checking > any preprocessor macros. It should be applied conditionally, i.e. > > has_version '>=app-text/poppler-0.18.0:0' && epatch "${FILESDIR}/this.patch" applied this one as such, thx! *** Bug 385929 has been marked as a duplicate of this bug. *** |