The configure script for gtk-doc will autodetect what binary to use to convert XML to PDF. It prefers dblatex but falls back to fop. Not sure if dblatex as installed by dev-tex/tex4ht is usable, as that isn't on the path normally. I guess we'd need a new ebuild for http://dblatex.sourceforge.net/ to support that. fop is provided by dev-java/fop on Gentoo, but won't be usable either as using that requires a file gtk-doc-fo.xsl which the build system doesn't install automatically. The really ugly part, though, is this: the autodetection is performed at compile-time, and the absolute path to the corresponding binary is hardcoded into the gtkdoc-mkpdf script. The dependencies in the ebuild do not mention any of these. As a consequence - some systems might build PDF successfully, others might fail trying, and yet others might not even try, all of this depending on the set of packages available at build-time. - binaries available at build-time might be missing at run-time, as the ebuild doesn't depend on them. All of this is ugly and against Gentoo style. So I suggest you either discuss improvements with upstream, or tweak the build process so that you can control the pdf generation mechanism independent from the set of installed binaries. You could add use flags (e.g. "dblatex" and "fop") to control which backend should be used for pdf generation. The script should follow that choice, as should the dependencies. And in the case of fop, the missing xsl file should be made available as well.
See bug #403165 for problems related to this issue, observed in the wild.
Created attachment 304541 [details, diff] Drop build-time magic This patch to configure.ac will simply pretend that dblatex and fop could not be found. It thereby drops the build-time magic, thus avoiding a factual dependency on a dblatex binary as well as the problems caused by the missing xslt file for fop. A future solution to this problem might be more elaborate: - The ebuild could offer USE flags to select a PDF generator, passing that choice to configure via AC_WITH directives which have to be patched in as well. - The gtkdoc-mkpdf script could select a suitable generator at runtime. Both of these require work, and might be better addressed upstream. So this patch here is a bare-bones solution: fix the core problem, and nothing more.
Created attachment 304543 [details, diff] Ebuild modifications These are the ebuild modifications required to apply the patch and recreate the configure script. Nothing special, but attached for the sake of completeness.
(In reply to comment #3) > Ebuild modifications in attachment 304543 [details, diff] Those are less than perfect: they cause the repeated execution of elibtoolize, which in turn causes warnings to be reported to the user, asking for a bug report. It looks to me as if both eautoreconf and gnome2_src_prepare would call elibtoolize unconditionally, so I see no easy way to avoid this. If this is in fact correct, a change to the eclasses to allow such scenarios would be nice.
Thank you for your analysis. Apparently, gtk-doc upstream feel that fop is unreliable enough that they comment it out by default. Bug #403165 is not caused by gtk-doc running fop, but by gtk-doc running xsltproc to prepare input for a fop run that never happens. In other words, autodetected fop in gtk-doc only causes build failures and serves no useful purpose whatsoever. I have therefore simply hard-disabled fop in gtkdoc-mkpdf in gtk-doc-1.18-r1, which should at least eliminate the build failures. However, the full solution is to use dblatex and depend on it via a USE flag (e.g. USE=pdf). For this, we first need dblatex in portage.
