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. At least until/unless pkgsrc bootstrap-mk-files switch to using ".dylib" on macOS (i.e. the default value of OBJECT_FMT, which is still "ELF" on Darwin-based systems, is fixed!) If I'm not mistaken Simon's mk-files are MUCH more portable and even quite long ago were already doing the right thing for Darwin/macOS -- I was quite surprised they were not the first choice for pkgtools/bootstrap-mk-files. > It'll need fixing up using the > install_name_tool dance like we do > elsewhere. That apparently that hasn't been a part of the devel/avltree build before -- or indeed of any package using a BSD Makefile to build a library! I guess I'm not too surprised given how relatively rare packages using BSD Makefiles currently are. > Monterey shouldn't be any different to Big > Sur where I still do regular bulk builds. So, are you telling me effectively that your macOS builds don't include devel/avltree? > You can compare against those if you think > you're running into issues that nobody > else is seeing: > > https://us-east.manta.joyent.com/pkgsrc/public/reports/Darwin/11.0/trunk/x86_64/20220226.2030/meta/report.html Thanks for the link -- I had not seen that page before! I don't feel quite so bad about all the build failures I've encountered now that I see your far more "impressive" list! Indeed you are telling me that your build of devel/avltree fails! And your logs show it is because of the same failure as I see. But since devel/avltree isn't used elsewhere (there isn't even a buildlink3.mk file for it), it's not a really good test of my fix. net/libfetch uses a BSD Makefile to build a library too, but it doesn't build a shared library..... (perhaps it should, but I would never argue for that -- I really like static libraries best) Another test I've found would be with my BSD Makefile version of devel/yajl and something that uses it, but, eg., sysutils/collectd-yajl only builds loadable modules, and it static-links libyajl.a into them (perhaps because bootstrap-mk-files keep the .so naming convention and do not use Mach-O's .dylib convention) The only other usable test I can find is net/librsync, which is actually used in several tools, but I've hacked that to use a BSD Makefile too, and my hacked version is not yet building on Monterey yet because of problems detecting the "blake2.h" file, so I'll have to fix that first.... > Just make sure you have all the correct > settings, especially things like > PREFER_PKGSRC=yes due to Apple breaking > shared libraries. The only change I've made from the bootstrap produced mk.conf was add the line for autoswc.mk to it. (and of course that's not used for devel/avltree because it uses a BSD Makefile) > I noticed you're still > using pdksh which indicates you haven't > bootstrapped in a long time. Sure, of course. I'm using pdksh, but only as my login shell. The message you saw was a result of my ERR trap for my interactive shell, not from anything done in the build. The pkgsrc bootstrap was done fresh on the new machine the other day, and there was no pkgsrc whatsoever on it beforehand. (Note that un-patched mksh since r56c has a fatal flaw that makes it unusable for a login shell, at least by me -- it doesn't double-eval $ENV any more!) BTW, I would feel a _LOT_ more comfortable if the bootstrap pkgsrc shell was a multi-byte capable shell, e.g. bosh. (though there may now be a maintenance issue for bosh and pbosh) Mksh is probably OK as a straight Unix interactive shell, with my patch to fix its handling of $ENV of course, but only barely. For a fully multilingual system like macOS there's just too much chance for multi-byte characters appearing anywhere and everywhere, including and especially in pathnames. Bash and ksh93 are multi-byte capable, but are big ugly monsters (and especially in the case of Bash, horribly slow too). I haven't got ksh93 to build on macOS yet either. That leaves bosh (and pbosh), and heirloom sh. I hope to test bosh as the bootstrap shell soon-ish. FYI, a reasonably simple test for multi-byte support in a POSIX-ish shell can be found here: https://github.com/robohack/experiments/blob/master/tmbIFS.sh One last thing for now: pkg_delete crashes every time on my system. (making pkgsrc on Monterey a "Hotel California" -- I can check things in, but never remove them! well at least not with the pkg tools) -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpls8LnoPQRG.pgp
Description: OpenPGP Digital Signature