icu 50 and how to identify dependents

Jeremy Huddleston Sequoia jeremyhu at
Sun Feb 10 01:17:07 PST 2013

On Feb 10, 2013, at 12:57 AM, Ryan Schmidt <ryandesign at> 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 which then made its way into 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.


More information about the macports-dev mailing list