OpenBLAS fixed in Xcode 11.2

[Ryan Schmidt]

On Nov 3, 2019, at 05:39, Jack Howarth wrote:

> On Sun, Nov 3, 2019 at 4:55 AM Ryan Schmidt wrote:
> 
>> The fact that the CLT SDK is now preferred is another reason why we want to go back to requiring the CLT. After Xcode 11 was released and Mojave users upgraded to it, we discovered just how pervasive the problem of SDK paths baked into build scripts was, as zillions of bug reports started pouring in about the MacOSX10.14.sdk being missing. Having the CLT installed on the build server ensures that any SDK paths that do get baked in will be for something that continues to exist even if Xcode is upgraded or is not present.
> 
> So you are saying that SDK paths are baked in as /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk (as the current CommandLineTools no longer installs in /). I'm rather surprised that folks bothered to hard code that path rather than just use `xcrun --show-sdk-path` to discover it. Is it really that hard to patch those build scripts to handle that properly?

I am saying that MacPorts supplies -isysroot and -syslibroot flags in CFLAGS and LDFLAGS when required so to do. It is required when building universal on a PowerPC Mac running Mac OS X 10.4; when on macOS 10.14 or later without /usr/include; or on any macOS version when the port or the user has requested to use an SDK different from the macOS version.

Some ports install -config scripts or other artifacts of the build process that are then used to build other ports. For example, perl might install a file with information about its configuration, which is then used later when building perl modules. That file might include the complete value of CFLAGS and LDFLAGS that was used to build perl, which would include any -isysroot and -syslibroot flags with the absolute SDK paths.

We discovered after users started upgrading from Xcode 10 (which has the 10.14 SDK) to Xcode 11 (which has the 10.15 SDK) that many users were experiencing errors about the 10.14 SDK being missing, because its path had been baked into something due to the above.

MacPorts used to always use SDK paths from Xcode. In MacPorts 2.6.0 it changed to prefer SDK paths from the command line tools, and only to use Xcode paths if "use_xcode yes" is specified in the Portfile. The command line tools SDK path shouldn't change when Xcode is upgraded, so this problem should be reduced due to this change.

Yes, it would be great it build systems did not bake this information into themselves. As we discover which build systems do this, we should fix them. It will be a never-ending process of looking out for and trying to fix these kinds of problems.