r102562 and #34056 wrt 10.5 pango +universal

[Jeremy Lavergne]

> I don't think pango uses graphite2; pango uses harfbuzz which uses graphite2. The graphite2 dependency was added to pango only because of my misunderstanding of dynamic libraries; the correct fix was not to add the graphite2 dependency to pango but to fix the .la files installed by all ports, which is now done in MacPorts base in trunk. See the recent "icu 50" discussion thread and ticket #38010.

Ah, that's something my setup caught: all my VMs use the specific revision of trunk I was using in my first build (I usually started in 10.8 and work down to 10.5), to ensure everything else stays in lockstep as I'm building in the other OSes.

This change went in during my builds!

>>> Can the muniversal portgroup help?
> 
> And you've been here how long? :)

I'm not as old as others! :) But I have managed to avoid some areas of the code (muniversal) while making use of some obscure stuff (old archives/mdmg).

> muniversal builds for each arch separately, then lipo's the results together. If the cmake portgroup has the limitation that there cannot be an i386 ppc universal build (which I had not remembered), then using muniversal should work around that problem, at the expense of longer build times and possible additional build problems, depending on the port.

Hmm, this optimistically sounds like it might work if it somehow can avoid (supposedly) Rosetta's bug. According to the ticket, PPC code effectively bootstraps at some point during build and just hangs. Now, is it bad PPC generated from a universal build or is it Rosetta choking on its own accord? I think Jeremy H is the authority here :)