On Feb 10, 2013, at 12:57 AM, Ryan Schmidt <[email protected]> wrote:

>>> I think I want to explicitly add a port:icu dependency to all ports using 
>>> pango to make these easier to find in the future.
>> 
>> No, please don't do that.  Only do that if the port actually links against 
>> icu.
> 
> Obviously I would only add the dependency if it actually links to icu. The 
> problem is that now that pango uses harfbuzz and harfbuzz uses icu, now 
> things that use pango use icu.

What makes you think that?  There's no reason to think that a port would use 
icu just because it's using pango.

> Maybe not all; I've been building ports for days and haven't come close to 
> trying all possibly affected ports yet. But I can give you some examples. If 
> you rebuild gtk2 or graphviz (which depend on pango) they use icu now.

That's odd.  If pango was actually exposing icu to clients, it should show up 
in 'pkg-config --libs pango' but it doesn't.

> Same with py27-pygtk (which depends on gtk2). Trying to unravel this is 
> becoming extremely tedious and I'm not sure if I should just continue, or 
> decide never to upgrade icu ever again, or remove icu from harfbuzz or what.

It looks like icu is being linked against even though it shouldn't be:

~/src/macports/dports/x11/pango $ nm -m /opt/local/lib/libpangoxft-1.0.dylib | 
grep icu

~/src/macports/dports/x11/pango $ otool -L /opt/local/lib/libpangoxft-1.0.dylib 
| grep icu
        /opt/local/lib/libicule.49.dylib (compatibility version 49.0.0, current 
version 49.1.2)
        /opt/local/lib/libicuuc.49.dylib (compatibility version 49.0.0, current 
version 49.1.2)
        /opt/local/lib/libicudata.49.dylib (compatibility version 49.0.0, 
current version 49.1.2)

It looks like the issue is glibtool suckage.  It landed in libharfbuzz.la which 
then made its way into libpangoft2-1.0.la when pango was rebuit and then made 
its way into anything that links against pango the next time it was rebuilt 
(even though it wasn't actually using it).

Why are we even shipping the .la files.  We should really just delete them from 
every destroot as they serve no useful purpose and always seem to just screw up 
builds.


--Jeremy

_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to