pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: macOS 12.x (Monterey) vs. pkgsrc

At Wed, 2 Mar 2022 07:12:47 +0000, Jonathan Perkin <> wrote:
Subject: Re: macOS 12.x (Monterey) vs. pkgsrc
> * On 2022-03-02 at 04:15 GMT, Greg A. Woods wrote:
> > # otool -XL
> > (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,

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

> 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

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

> You can compare against those if you think
> you're running into issues that nobody
> else is seeing:

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 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 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:

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 <>

Kelowna, BC     +1 250 762-7675           RoboHack <>
Planix, Inc. <>     Avoncote Farms <>

Attachment: pgpls8LnoPQRG.pgp
Description: OpenPGP Digital Signature

Home | Main Index | Thread Index | Old Index