On Sun, 3 Apr 2022, Joshua Root wrote:
On 2022-4-3 14:05 , Fred Wright wrote:
lrwxr-xr-x 1 root wheel 15 Sep 26 2020 MacOSX.sdk -> MacOSX10.15.sdk
drwxr-xr-x 7 root wheel 224 Sep 26 2020 MacOSX.sdk 1
lrwxr-xr-x 1 root wheel 10 Aug 17 2019 MacOSX10.14.sdk -> MacOSX.sdk
drwxr-xr-x 8 root wheel 256 Nov 7 2019 MacOSX10.15.sdk
I'm pretty sure I never changed anything there, other than by running Apple
installers. I wouldn't be surprised if "MacOSX.sdk 1" is really a 10.14
SDK, but I didn't dig into it.
Having MacOSX10.14.sdk ultimately pointing to MacOSX10.15.sdk is probably
going to cause problems. On my 10.14 system it looks like this:
% ls -l /Library/Developer/CommandLineTools/SDKs
total 0
drwxr-xr-x 7 root wheel 224 9 Jul 2019 MacOSX.sdk
drwxr-xr-x 5 root wheel 160 12 May 2018 MacOSX10.13.sdk
lrwxr-xr-x 1 root wheel 10 4 Oct 2019 MacOSX10.14.sdk -> MacOSX.sdk
% plutil -p
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/SDKSettings.plist | fgrep
\"Version\"
"Version" => "10.14"
The fact that you have no 10.15 SDK at all suggests that you're running
Xcode 10.x, though up through 11.3.1 runs on 10.14. I usually run the
latest Xcode for each OS version, which is what the MacPorts documentation
recommends.
Using the unversioned name for the real directory and the versioned name
for the symlink is rather backwards, but it seems to be par for the
course.
On Sun, 3 Apr 2022, Christopher Chavez wrote:
Thank you for testing. However the proposed change is specifically to
allow building with the 10.14 SDK, and so what I wanted to be sure of is
whether it actually worked with the 10.14 SDK; I expected there to
already not be any problems building with the 10.15 SDK on macOS 10.14.
Well, you didn't say that. :-)
I rearranged the SDKs to look like this:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs:
total 0
drwxr-xr-x 4 fw wheel 128 Nov 7 2019 DriverKit19.0.sdk
lrwxr-xr-x 1 fw wheel 15 Apr 4 14:10 MacOSX.sdk -> MacOSX10.14.sdk
lrwxr-xr-x 1 fw wheel 56 Apr 3 15:47 MacOSX10.14.sdk ->
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
drwxr-xr-x 8 fw wheel 256 Nov 7 2019 MacOSX10.15.sdk
/Library/Developer/CommandLineTools/SDKs:
total 0
lrwxr-xr-x 1 root wheel 15 Apr 3 15:30 MacOSX.sdk -> MacOSX10.14.sdk
drwxr-xr-x 7 root wheel 224 Sep 26 2020 MacOSX10.14.sdk
drwxr-xr-x 9 root wheel 288 Apr 3 15:30 MacOSX10.15.sdk
So both 10.14 and 10.15 SDKs are available, to both GUI Xcode and CLT,
with 10.14 as the default. I still get the warning, though it looks like
it probably comes from base rather than the port. The beginning of the
logfile looks like this:
DEBUG: Starting logging for qt6-qtbase @6.2.1_4+openssl
DEBUG: macOS 10.14.6 (darwin/18.7.0) arch i386
DEBUG: MacPorts 2.7.2
DEBUG: Xcode 11.3.1
DEBUG: SDK 10.14
DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.14
Warning: The macOS 10.14 SDK does not appear to be installed. Ports may not
build correctly.
Warning: You can install it as part of the Xcode Command Line Tools package by
running `xcode-select --install'.
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: xz 5.2.5_0 exists in the ports tree
So something isn't right with the SDK check.
Meanwhile, it looks like the update was already pushed, since I had to
fight the port command's refusal to honor -s during further testing. It
seems that an explicit clean is needed to make -s work, in spite of the
two alleged cleans during the uninstall.
Fred Wright
