On Feb 10, 2013, at 03:17, Jeremy Huddleston Sequoia <[email protected]> wrote:
> > 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. 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. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
