icu 50 and how to identify dependents

[Jeremy Huddleston Sequoia]

>>>> 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.
>> 
>> Yeah, that's the problem.  Look at the output of nm -m, and you'll see it's not actually using icu.  It's just linking against it because of glibtool's viral propagation of linkage.
> 
> What I mean is that I get messages that libraries a program or library links with cannot be found. In that sense at least, they are being "used". Therefore I revbump the affected port to rebuild it with the current version of the library and thus clear the error.

Yep, because of glibtool suckage, we need to rebump everything that depends indirectly on icu (through pango) and builds with glibtool … even packages that seem ok to you because you happened to have built them before pango was updated (because someone else may have built it after the viral spread of that link by glibtool).

>>>> 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.
>> 
>> .la files are "instructions" that glibtool leaves for itself on how it should link against a particular library.  They're sometimes useful on other platforms, but on OS X, they serve absolutely NO useful purpose.
> 
> Then I'm surprised MacPorts has gone 11 years already without removing them. Do other OS X package managers remove them?

I don't know about fink or homebrew, so I can't comment there, but I certainly removed them from XQuartz after they messed things up quite a bit for X11 users.  There were also a handful of them shipped with OS X (in /usr/lib), but we got rid of them in Snow Leopard.