icu 50 and how to identify dependents

[Jeremy Huddleston Sequoia]

On Feb 10, 2013, at 1:09 AM, Ryan Schmidt <ryandesign at macports.org> wrote:

> It's similar to what's been going on all day with jpeg and tiff. Ports that depend on jasper also link with libjpeg, and so they need a revbump now. Ports that depend on GraphicsMagick also link with libjpeg and libtiff; I've had to revbump php-gmagick for that. Curiously I haven't had to do the same for php-imagick, which uses ImageMagick.
> 
> Is this a fault in GraphicsMagick, jasper, harfbuzz, etc.? For example:

No, it's a fault of glibtool not understanding the difference between what a library needs to link against and what the client of the library needs to link against.

> $ GraphicsMagick-config --libs
> -lGraphicsMagick -llcms2 -ltiff -lfreetype -ljasper -ljpeg -lpng15 -llzma -lbz2 -lxml2 -lz -lm -lpthread
> 
> $ grep -- -licu /opt/local/lib/libharfbuzz.la
> dependency_libs=' -R/opt/local/lib -L/opt/local/lib /opt/local/lib/libgobject-2.0.la /opt/local/lib/libgthread-2.0.la /opt/local/lib/libffi.la /opt/local/lib/libglib-2.0.la -lresolv /opt/local/lib/libintl.la /opt/local/lib/libiconv.la -lc /opt/local/lib/libfreetype.la -lz -lbz2 /opt/local/lib/libgraphite2.la -licule -licuuc -licudata'
> 
> Should these libraries not be listed there? If so should we fix GraphicsMagick et al to not list these libraries? We then still have to revbump everything using them to get them to no longer link with those libraries.

You should check 'nm -m <binary>' to determine what it actually uses.  glibtool is just overzealous and assumes that it's safer to have the final executable link against *everything*.    We'd be doing ourselves a favor if we forced a global post-destroot that just deleted ${prefix}/lib/*.la and added a verification step that ensured every link was actually relevant.

--Jeremy