* 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, > fix. 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 pkgsrc tree.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 similar error.
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