At Sat, 19 Mar 2022 08:39:56 -0500, Jason Bacon <jtocino%gmx.com@localhost> wrote:
Subject: Re: Darwin/macOS: Xcode upgrades vs. pkgsrc
>
> On 3/18/22 13:32, Greg A. Woods wrote:
> > A recent Xcode upgraded forced me to make the following change.
> >
> > However as my comment suggests I think this whole OSX_SDK_MAP mess is
> > fundamentally the wrong approach:
> >
> > --- Darwin.mk.~1.113.~ 2022-02-25 13:29:47.931821426 -0800
> > +++ Darwin.mk 2022-03-18 11:28:21.527119242 -0700
> > @@ -111,11 +111,21 @@
> > # Apple do not always keep the SDK version in step with the OS version. When
> > # that happens add a mapping below, but only within the same OS release major.
> > #
> > +# XXX this is the wrong approach -- the best default is to use the default!
> > +# (I.e. OSX_TOLERATE_SDK_SKEW should effectively always default to "yes" given
> > +# the existing logic.)
> > +#
> > +# Xcode does not easily allow installation of different version-specific SDKs,
> > +# and the default SDK can radically change with any Xcode upgrade, HOWEVER, the
> > +# default installed SDK will, or at least should, always work for the host
> > +# platform.
> > +#
> > OSX_SDK_MAP.11.2= 11.1
> > OSX_SDK_MAP.11.4= 11.3
> > OSX_SDK_MAP.11.5= 11.3
> > OSX_SDK_MAP.11.6= 11.3
> > OSX_SDK_MAP.12.2= 12.1
> > +OSX_SDK_MAP.12.1= 12.3
> > #
> > OSX_SDK_PATH!= /usr/bin/xcrun \
> > --sdk macosx${OSX_SDK_MAP.${OSX_VERSION}:U${OSX_VERSION}} \
>
>
> Yes, we need a smarter system to prevent breakage by macOS updates and
> Xcode version skew. We should aim to try out alternatives shortly after
> the branch so we have most of the next quarter to fully test.
There's nothing really to figure out.
Fixing this entirely as I suggested by dropping all mention of
OSX_VERSION and the OSX_SDK_MAP _is_ really very simple actually, and
completely fool proof and future proof.
After all one downloads and installs Xcode and it builds binaries that
work for the host system, and similarly one upgrades Xcode, or lets it
be auto-upgraded, and again it continues to build binaries that work for
the host system. Pkgsrc should really NEVER be concerned with the
specifics of SDK versions. There is actually no version skew if the
default SDK is always used.
I.e. just _always_ use the default SDK!
I personally would argue that it's even simple and important enough to
do _before_ the next quarterly branch (but then I'm less conservative
than many, including those who might actually implement this decision).
The rest of this below is an explanation to try to dissuade people from
thinking the SDK version has anything whatsoever to do with achieving
backward compatability of products one builds with that SDK, if indeed
that's why this mess was created in the first place.
So, the choice of SDK version is entirely separate from the way one
builds binaries that are backward compatible to older systems with
Xcode. One (_always_) compiles against the latest (i.e. currently
installed default) SDK, but you can set the "Minimum Deployment Target"
(as it's called in Xcode) to the earliest macOS version you wish your
binaries to run on. This is done with Clang on the command line using
something like this option in both CFLAGS and LDFLAGS:
-mmacosx-version-min=10.9
One can see the result for a binary with "vtool -show binary".
Of course because there's also the caveat that the code being compiled
must be fully compatible with being built for and run on the older
target. This can mostly be assured by adding to CPPFLAGS:
-Werror=partial-availability
and to LDFLAGS:
-Wl,-no_weak_imports
Of course this can still get partially messed up by autoconf (and
possibly CMake), though mostly the build or link will still fail when it
should.
So one must be very careful if one wants to target earlier systems.
Trying to build for older releases by hacking in older SDKs is just
asking for problems as the older SDKs are inevitably more buggy, and
perhaps less compatible with the current compiler!
BTW, things get really complicated if one wants to build universal
binaries that support the earliest reasonable release for each
architecture. This is not a problem pkgsrc itself can easily solve as
it would require deep dives into the build scripts for most packages
since multiple binaries need to be built for each program and then
stitched together into a universal binary with "lipo".
Aside from building for older systems, the only real caveat related to
pkgsrc use of Xcode is that pkgsrc requires the command-line utilities,
and Xcode updates have a history of not also automatically updating the
command-line utilities, and/or occasionally disabling them. However
that's all very separate from the choice of SDK or attempts to support
backwards compatability.
--
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:
pgpwsOVLz26v5.pgp
Description: OpenPGP Digital Signature