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