[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: macOS 12.x (Monterey) vs. pkgsrc
* On 2022-03-02 at 22:12 GMT, Greg A. Woods wrote:
At Wed, 2 Mar 2022 21:29:35 +0000, Jonathan Perkin <jperkin%joyent.com@localhost> wrote:
Subject: Re: macOS 12.x (Monterey) vs. pkgsrc
* On 2022-03-02 at 21:09 GMT, Greg A. Woods wrote:
> At Wed, 2 Mar 2022 07:12:47 +0000, Jonathan Perkin <jperkin%joyent.com@localhost> wrote:
> Subject: Re: macOS 12.x (Monterey) vs. pkgsrc
>> * On 2022-03-02 at 04:15 GMT, Greg A. Woods wrote:
>> > # otool -XL libavltree.so.1.1
>> > libavltree.so.1.1 (compatibility version 0.0.0, current version 0.0.0)
>> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)
>> > I'm thinking mk/check/check-shlibs-macho.awk should not complain if then
>> > library depends on itself like this?
>> No, it needs to be correct, otherwise any
>> binaries or libraries that link against it
>> will also be incorrect, and then it's
>> impossible to do any meaningful checks.
> Well, I don't know all the details of macOS dylib, but I think Mansour's
> reply suggests my fix is indeed the, or at least a sufficiently correct,
It's nothing of the sort. It completely
breaks the entire REQUIRES logic. Just do
a post-install fixup, there are plenty of
examples of how to do that across the
You'll have to be a lot more explicit and technically detailed than that
to help me to understand.
The REQUIRES logic isn't affected at all so far as I can tell.
It's pretty simple, REQUIRES and PROVIDES must be full paths to the
libraries. Your "fix" means that the PROVIDES for libavltree and the
REQUIRES for any packages that depend on it will simply list
"libavltree.so.1.1" rather than e.g. "/opt/pkg/lib/libavltree.so.1.1",
and any attempt to install those packages using pkgin or similar will
result in a "libavltree.so.1.1 is not available on this system" or
Anyway, rather than more talk, I already committed a fixup of the
library as I suggested earlier, and the package now builds on macOS.
I agree that it's not an ideal fix, but only from the point of view that
using .so naming conventions is wrong for Darwin in the first place, and
that the better fix would involve either replacing, or hacking on,
bsd.lib.mk from bootstrap-mk-files. As part of that what Mansour
suggested can also be applied safely in a target-specific manner.
Doing what you suggest also requires hacking on bootstrap-mk-files.
That's the only way to make a correct fix that'll apply transparently to
any current and/or future packages using BSD Makefiles.
Just to be clear I'm definitely in favour of someone working on an
update for bootstrap-mk-files. The problem is that it's an absolutely
crazy amount of work to verify that merging over a decade of changes
from upstream won't break any of the 20+ platforms we support, and as
yet nobody has stepped up to be responsible for doing this, mostly
because the risk is monumental and the rewards are microscopic.
Jonathan Perkin - Joyent, Inc. - www.joyent.com
Main Index |
Thread Index |