On Feb 10, 2013, at 1:49 AM, Ryan Schmidt <[email protected]> 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
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
