icu 50 and how to identify dependents

Ryan Schmidt ryandesign at macports.org
Sun Feb 10 01:27:03 PST 2013


On Feb 10, 2013, at 03:21, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:

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

I haven't used the nm tool before and am not familiar with its output.

We just had a release of MacPorts so it might be awhile before we have another one, and any such global post-destroot to remove .la files would have to be coded first, and its consequences understood.

Meanwhile, what do we do today? Not update icu? And what will we do once the .la removal code you talk about is added? Won't we have to revbump almost every port?



More information about the macports-dev mailing list