icu 50 and how to identify dependents

[Jeremy Huddleston Sequoia]

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

> 
> On Feb 10, 2013, at 03:38, Jeremy Huddleston Sequoia wrote:
> 
>> 
>>>>>> 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).
> 
> I noticed pangox-compat doesn't link with icu even if I rebuild it now. Any idea why it's immune? It does build with libtool. It's its own copy of GNU libtool built at configure time, not MacPorts glibtool.

The copy of glibtool it uses shouldn't matter.  I don't know.  Is pangox-compat not linking against harfbuzz?

>>>>>> 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.
> 
> There are still .la files in /usr/lib on Mountain Lion (in /usr/lib/freeradius and /usr/lib/sasl2)

~ $ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.8.2
BuildVersion:	12C60

~ $ ls /usr/lib/*la
gls: cannot access /usr/lib/*la: No such file or directory

I didn't see those ones in freeradius and sasl2 … time to file a radar =)

> , and many in MacPorts in directories other than /opt/local/lib.

Yeah, pretty much any port which builds a library with glibtool (which is the overwhelming majority of OSS libraries) will be in this boat.

> Can we just go nuts and fs-traverse ${destroot} and remove all .la files wherever they might be? We could use `file` to make sure they're text files before doing so, in case some weird software somewhere uses its own .la files that are not libtool files.

I once got pissed at MacPorts and just nuked /opt/local/lib/*.la and nothing bad ever happened to me.

--Jermey