what say we just use MacOSX.sdk preferentially on BigSur and up?

[Ryan Schmidt]

On Dec 31, 2020, at 15:54, Ken Cunningham wrote:

> On Dec 31, 2020, at 1:51 PM, Ryan Schmidt wrote:
> 
>> On Dec 31, 2020, at 10:56, Ken Cunningham wrote:
>> 
>>> So I will make another push for this, before we get hundreds of ports built with incorrect burned-in SDKs that make a total mess for us to manage.
>>> 
>>> 
>>> What is different now is that almost all current configure software does a test-compile and run rather than look for a specific header or function to be defined, and if they don’t, they will need to.
>> 
>> We have a lot of non-current software in MacPorts.
>> 
>> And I don't know what evidence you have that "almost all current configure software" does things correctly. I find that hard to believe.
> 
> Let’s test then.
> 
> I have my three 10.13 systems set up with Xcode 10 and the last SDK it came with. Two of those are capped-out at 10.13 due to hardware, one is a VM.
> 
> Happy to throw anything you like at it, and see if we can break it.
> 
> You know I’m only involved in this issue to make all our lives easier,

I agree with what Josh has said many times before, that nothing has fundamentally changed about how non-Mac software developers write their code. They are not aware of macOS SDKs and how symbols that are available in the SDK might not be available at runtime. It's a never-ending battle to explain this to developers and get them to agree to accommodate it. Therefore the way to make all our lives easier it to use the SDK that matches the OS version, and that's what I try to do by keeping older Xcode versions on the buildbot machines.

We want to avoid ports installing files that contain the specific SDK path. Some ports do so only for information so it doesn't matter. Others might use those values later to build other software, like maybe python recording the SDK path to use it to build python modules later. In those cases, we should replace the SDK path with the generic unversioned SDK path that exists on all systems. This is not a new problem in macOS 11; it has been a problem anytime we use an SDK, and certainly since 10.14.

A similar problem is when build systems save the compiler that was used into files that get installed and then try to use that compiler later to build other modules; perl does this. And this causes problems like https://trac.macports.org/ticket/59786. The solution is the same: replace the specific compiler path in the installed files (e.g. /opt/local/bin/clang-mp-3.4) with the generic compiler (/usr/bin/cc) that exists on all systems. (The even better solution is to explain to those projects that they should stop saving the compiler name into their installed files and stop trying to use it later; instead, they should always obey the CC and CXX environment variables.)


> and specifically, so that 10.13 can get the current qt 5.15.2 on the buildbot so that everyone can enjoy it like I can.

That's

https://trac.macports.org/ticket/61921

and according to that, using a newer compiler might be all that's needed to get that to work, and there may just be a bug in the qt build system that does not accept arbitrary compilers, in which case it would be good to fix that bug. We don't necessarily have to be the ones to figure out how to fix the bug; we can start by reporting it to the developers of qt; maybe they will immediately know how to fix it.