icu 50 and how to identify dependents

[Ryan Schmidt]

On Feb 10, 2013, at 03:49, Jeremy Huddleston Sequoia wrote:

> nm shows you what symbols are provided by the binary and which symbols it needs.  With 'nm -m' you will see more verbose output including where the library resolves undefined symbols to.  As a quick example of how much crud is being linked which isn't needed, this first line shows what libpangocairo actually needs:
> 
> ~ $ nm -m /opt/local/lib/libpangocairo-1.0.dylib | grep 'undefined' | sed 's:^.*(from \(.*\)).*$:\1:' | sort -u
> libSystem
> libcairo
> libfontconfig
> libfreetype
> libglib-2
> libgobject-2
> libpango-1
> libpangoft2-1
> 
> And this is what it's linking against:
> 
> ~ $ otool -L /opt/local/lib/libpangocairo-1.0.dylib
> /opt/local/lib/libpangocairo-1.0.dylib:
> 	/opt/local/lib/libpangocairo-1.0.0.dylib (compatibility version 3201.0.0, current version 3201.5.0)
> 	/opt/local/lib/libpango-1.0.0.dylib (compatibility version 3201.0.0, current version 3201.5.0)
> 	/opt/local/lib/libcairo.2.dylib (compatibility version 11203.0.0, current version 11203.12.0)
> 	/opt/local/lib/libpixman-1.0.dylib (compatibility version 29.0.0, current version 29.2.0)
> 	/opt/local/lib/libpng15.15.dylib (compatibility version 30.0.0, current version 30.0.0)
> 	/opt/local/lib/libxcb-shm.0.dylib (compatibility version 1.0.0, current version 1.0.0)
> 	/opt/local/lib/libX11-xcb.1.dylib (compatibility version 2.0.0, current version 2.0.0)
> 	/opt/local/lib/libxcb-render.0.dylib (compatibility version 1.0.0, current version 1.0.0)
> 	/opt/local/lib/libXrender.1.dylib (compatibility version 5.0.0, current version 5.0.0)
> 	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
> 	/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
> 	/opt/local/lib/libxcb.1.dylib (compatibility version 3.0.0, current version 3.0.0)
> 	/opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current version 7.0.0)
> 	/opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current version 7.0.0)
> 	/opt/local/lib/libpangoft2-1.0.0.dylib (compatibility version 3201.0.0, current version 3201.5.0)
> 	/opt/local/lib/libgmodule-2.0.0.dylib (compatibility version 3401.0.0, current version 3401.3.0)
> 	/opt/local/lib/libharfbuzz.0.dylib (compatibility version 913.0.0, current version 913.0.0)
> 	/opt/local/lib/libgobject-2.0.0.dylib (compatibility version 3401.0.0, current version 3401.3.0)
> 	/opt/local/lib/libgthread-2.0.0.dylib (compatibility version 3401.0.0, current version 3401.3.0)
> 	/opt/local/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.0.0)
> 	/opt/local/lib/libglib-2.0.0.dylib (compatibility version 3401.0.0, current version 3401.3.0)
> 	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 41.1.0)
> 	/opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0)
> 	/opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
> 	/opt/local/lib/libgraphite2.3.dylib (compatibility version 3.0.0, current version 3.0.1)
> 	/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)
> 	/opt/local/lib/libfontconfig.1.dylib (compatibility version 8.0.0, current version 8.2.0)
> 	/opt/local/lib/libfreetype.6.dylib (compatibility version 16.0.0, current version 16.0.0)
> 	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
> 	/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.6)
> 	/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.0.0)
> 	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0)

So to ensure that this crud is cleaned up and does not propagate further it seems to me that we would want to rebuild everything at once in the correct order, i.e. revbump everything.


>> 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.
> 
> Well, it's consequences are that glibtool will no longer propagate dependencies like a virus.

That sounds good!


>> Meanwhile, what do we do today? Not update icu?
> 
> No, icu is actually kind of important … and unfortunately, it's kind of a root project.  I'm not sure the best answer here.

I'll hold off on updating it for now until we know what we're doing. Just updating icu and revbumping only the ports that declare a dependency on icu will clearly cause lots of breakage that I'd like to avoid.


>> And what will we do once the .la removal code you talk about is added? Won't we have to revbump almost every port?
> 
> At minimum, we should poke the buildbots to do a rebuild.  I don't think a revbump would be warranted for every port.  The situation would clear itself up as ports bumped themselves.  The risk in not bumping is that someone might still have a viral link which we didn't account for when we update something again in the future, but rev-upgrade should catch those cases.

I was going to disagree with you until you said rev-upgrade, and then I had to think for a minute. I often forget we have rev-upgrade because I have it turned off on my main machine, and set to report only on my other machines.

Poking the buildbots to rebuild everything without .la files would take care of new installs. It's already been suggested we should update the buildbots to Xcode 4.6 and rebuild all binaries with that. So we could take care of both at once.

I wonder if many of our users have rev-upgrade turned off, and if so, if they will know what to do when stuff breaks, especially since the fallout will occur over a long period of time, probably years, until every port has coincidentally been updated or rebuilt.

I worry that references to .la files would remain in ports somewhere even if library linkage was not broken, such that rev-upgrade would not trigger a rebuild and these relics would cause problems later. I'm not sure if that worry makes sense.