On Nov 18, 2009, at 12:05 AM, Luca Marturana wrote:
>
> Il giorno 16/nov/2009, alle ore 18.46, Bradley Soto ha scritto:
>
>> Check
>>
>> http://trac.macports.org/ticket/20924
>
> If I'm understanding correctly the discussion, the problem is that Pango uses an old Carbon Library that Snow Leopard doesn't support anymore, so the only solution is to port pango to the new Framework used by Apple right?
>
Hmm pango worked for me for some time (SL x84 prefix USE=aqua). Versions prior to 1.26 with some patching and 1.26 out of the box -- used them in my personal overlay (see http://user.cs.tu-berlin.de/~zuxez/private/gtk-demo.png). There's only a font rendering ligature issue, which depends on some specific fonts to occur. Iirc that warning you're encountering was there in old versions of pango (prior to 1.26) and/or some weird gtk styles -- and it's still a warning, not an error ;)
Ah and after removing my overlay's version of pango, I just noticed that the prefix pango-1.26.ebuild in the SVN repo needs a minor fixup. Fabian, the ebuild needs
if [[ ${CHOST} == *64-apple-darwin* ]] ; then
# Carbon is dead in 64-bits land
export ac_cv_header_Carbon_Carbon_h=no
fi
removed, otherwise it'll runtime-segfault on all gtk invocations. The problem is, that this completely turns off quartz font rendering:
"checking which cairo font backends could be used... freetype"
while without that ac-hacking it reads
"checking which cairo font backends could be used... quartz freetype"
From the segfault i'd guess the freetype backend doesn't even work on osx. My ebuild worked for me, because I did not have that ac-hack in there. And Carbon.h is *not* completely dead in 64bit, but many functions are. Pango 1.26 just doesn't use those 32bit-only functions, but other functionality that is included with Carbon.h I assume.
And I guess that
eautoreconf
elibtoolize # for Darwin bundles
can be shortened to just read
eautoreconf
That autoconf call wasn't there in previous versions...
Kind regards,
Heiko.
|
