PR 14427: 10.14 tester wanted

[Fred Wright]

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