icu 50 and how to identify dependents

[Ryan Schmidt]

On Feb 10, 2013, at 03:17, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote:

> 
> On Feb 10, 2013, at 12:57 AM, Ryan Schmidt <ryandesign at macports.org> 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.

The output of otool -L.

>> 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.

I don't know what .la files are for so I'm not in a position to be able to assert that we should remove them.