Building a large science software package on macOS11.6 with only the Command Line Tools (CLT) installed (Xcode is not installed).
All was working while MacOSX11.sdk was the newest SDK (which was true when the project started last year), but a recent re-install of CLT advanced support to MacOSX12.sdk which adds one new method to NSBundle.h (localizedAttributedStringForKey) that is tripping up clang. Isolated testing shows compiling against MacOSX11.sdk does still work correctly.
Since CLT's default is to use the most recent SDK, builds now fail with a compilation error when Foundation's NSBundle.h is reached.
Installing CLT creates SDK directories for the range of versions of macOS that are supported by the equivalent Xcode for example (from a Monterey Mac):
√ ~ % ls -l /Library/Developer/CommandLineTools/SDKs
total 0
lrwxr-xr-x 1 root wheel 14 Mar 15 10:23 MacOSX.sdk -> MacOSX12.3.sdk
drwxr-xr-x 7 root wheel 224 Nov 30 2020 MacOSX11.1.sdk
drwxr-xr-x 7 root wheel 224 Mar 15 10:24 MacOSX11.3.sdk
lrwxr-xr-x 1 root wheel 14 Mar 15 10:23 MacOSX11.sdk -> MacOSX11.3.sdk
drwxr-xr-x 7 root wheel 224 Feb 23 11:14 MacOSX12.3.sdk
lrwxr-xr-x 1 root wheel 14 Mar 15 10:23 MacOSX12.sdk -> MacOSX12.3.sdk
√ ~ %
I believe there is no way to set the global environment to select the SDK that CLT should use for headers, libraries, etc. Two low-level options are to (1) change to xcrun —sdk *** clang or (2) use -isysroot to select the MacOSX11.sdk includes, but changing the many, many makefiles to do either is unacceptable (and would need conditionals for Linux).
Is there a way to coerce CLT to not use the most recent SDK?
xcode-select -s .. has been mentioned in other forums but is irrelevant because there is no Xcode on the Mac. And, since this package will be distributed to people for whom make is the tool of choice, Xcode is not an option.
PS: my theory is that the new localizedAttributedStringForKey method needs a Monterey version of clang with a new feature related to concurrency support and Big Sur gives you an older clang without that feature, hence compiler barfing .. Gavin Eadie, Ann Arbor MI
