Bug 104308 – xpdf-3.01-r8 builds fine on ppc-macos

• Product: Gentoo/Alt
• Status: RESOLVED CANTFIX

[Description Thomas Kjosmoen 2005-08-30 15:25:00 UTC]

As title says, it builds fine on ppc-macos.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

[Comment 1 Fabian Groffen 2005-08-31 02:56:50 UTC]

(dependencies are for convenience to myself here)
[ebuild  N    ] x11-libs/motif-config-0.9  0 kB [1] 
[ebuild  N    ] x11-libs/openmotif-2.2.3-r7  0 kB [1] 
[ebuild  N    ] media-libs/t1lib-5.0.2  -X (-doc) 0 kB [1] 
[ebuild  N    ] app-text/xpdf-3.00-r10  +motif -nodrm +truetype 522 kB [1] 


tested USE flags to work on the PDF version of "Vi Improved by Steve Oualline"

When using "motif nodrm" I get no xpdf, configure:
configure: WARNING: Couldn't find X / Motif -- you will be able to compile
        pdftops, pdftotext, pdfinfo, pdffonts, pdftoppm, and pdfimages,
        but not xpdf

while "motif nodrm truetype" or "motif truetype" or "truetype" works fine. 
Seems like the truetype USE flag does the trick, but it requires to set it,
before compilation yields into something one would expect.  "-motif" has the
same effect of not creating the xpdf executable.

[Comment 2 Thomas Kjosmoen 2005-08-31 09:34:05 UTC]

Ah, I should have specified "builds fine using the default USE flags for ppc-macos." (I.e. -motif -nodrm -
truetype.)

[Comment 3 Fabian Groffen 2005-08-31 11:21:09 UTC]

well, it builds fine in any case, but it fails to find motif (meaning actually
building xpdf) in my mentioned situation, indicating somehow something goes
wrong there in comparison with x86

[Comment 4 Thomas Kjosmoen 2005-08-31 11:27:38 UTC]

I found this one in the configure file for xpdf:

if test "x$smr_have_freetype2_library" != xyes; then
  no_x="yes"
fi

This would certainly mean that we HAVE to have freetype2 in order to get the xpdf binary. Weird, really. 

[Comment 5 Fabian Groffen 2005-08-31 11:29:56 UTC]

well, it makes sense for what the configure does, but it doesn't make sense on
x86 this doesn't hold.  I'll have to look into this... :/

[Comment 6 xalan 2006-06-13 10:55:24 UTC]

Created attachment 89057 [details]
The test pdf.

[Comment 7 Fabian Groffen 2006-06-13 11:08:02 UTC]

what does this test.pdf file mean?

[Comment 8 Emanuele Giaquinta (RETIRED) 2006-06-19 15:07:49 UTC]

The original version builds fine, setting CXXFLAGS/LDFLAGS properly, but the one we have in the tree is a modified one that uses poppler, and poppler requires fontconfig-2 to build; now fontconfig has the ppc-macos keyword, but I've just noticed there is a collision on /etc/fonts/fonts.{conf,dtd}. If I'm not missing something we should package.mask fontconfig and close this as CANTFIX.

[Comment 9 Fabian Groffen 2006-06-20 00:32:54 UTC]

I will try fontconfig tonight* to see if it collides for me too.

* disclaimer: need not necessarily be today :)

[Comment 10 Fabian Groffen 2006-06-22 10:16:28 UTC]

xpdf needs poppler, which wants >=automake-1.9, which is p.masked on OSX.  No go.

[Comment 11 Emanuele Giaquinta (RETIRED) 2006-06-22 10:22:58 UTC]

That one is a useless dep and can go away; the problem with poppler is the one described in comment #8.

[Comment 12 Fabian Groffen 2006-06-22 10:33:52 UTC]

get the dep fixed and reopen this bug.

[Comment 13 Emanuele Giaquinta (RETIRED) 2006-06-22 10:50:23 UTC]

... done; but there is no point in reopening this bug.

[Comment 14 Fabian Groffen 2006-06-22 12:59:48 UTC]

This is interesting, I get no collisions for fontconfig.  Poppler hasn't got its own bug for this?  Interesting.

Ohw wait... portage 2.1.1 is broken with regard to collision protect.  FUCK!