pstoedit will compile without libemf. This allows it to compile cleanly on amd64 archs, simply missing support for EMF (which is some windows crud anyway so who cares ;) ). perhaps a useflag is in order? also note bug #107440, which involves the underlying 64-bit compatibility problem in libemf. It's resolution may make this bug moot, although at that point amd64 should be added to both libemf and pstoedit ebuilds.
text-markup: is adding a USE flag or dropping the libEMF dep acceptable?
From what I read, EMF is used for importing in OOo (which you can qualify of windows crud, though :) ), so I don't think dropping it is acceptable. Making it a USE flag seems a lot better to me. whereami: can you provide an ebuild for this?
Created attachment 86983 [details] pstoedit-3.42.ebuild
(In reply to comment #2) > whereami: can you provide an ebuild for this? certainly. I've attached a modified 3.42 ebuild that adds the use flag. However, I noticed a note in the ebuild: # secondly, we're not enabling libemf via a use flag, until it's # actually switchable via configure, see bug #39557 (the attached ebuild removes this comment to avoid confusion) Bug #39557 doesn't make the reason behind this policy clear. Added obz to the CC list so he can share his views. Also, I suggest making this ebuild enabled by default on the archs that can build libemf: x86, ppc, ppc64, sparc (according to the libemf-1.0 ebuild)
(In reply to comment #4) > Also, I suggest making this ebuild enabled by default on the archs that can And by ebuild, i mean the libemf use flag... sorry, typo.
Added a emf use flag which pulls libemf to the 3.42 ebuild which only works on non amd64 (since libemf does not work on amd64) and then added the ~amd64 keyword.
