building gdb with newer clangs on 10.7 and Xcode <4.4

[Ken Cunningham]

So the reason Jeremy set these tool wrappers up to be invoked by xcrun is that xcrun adds a number of useful default settings ("sugar") and envvars to the toolchain. 

This does things like spec the appropriate sdkroot, etc… a reasonable summary is here:

https://keith.github.io/xcode-man-pages/xcrun.1.html

You will see people saying their builds can't find the SDK, for example, and trying to set that in their bootup shell scripts -- but that's often because they aren't using Apple's tools the right way. Jeremy, being a compiler engineer for Apple, certainly knew the right way.

There are nearly 40,000 buildable ports on Macports, and they have all been tested to build with the current setups. Changing core things like this can have untold and widespread effects.

It sounds like you are trying to build some things with an old version of the developer tools on 10.7 and running into troubles. Perhaps the xcrun in those older versions doesn't work the way the last set of developer tools works on 10.7.

This generates a question - should MacPorts be modified, possibly in an unfavourable way, to allow folks to do things like this? My vote has always been no -- MacPorts can really only be expected to support one consistent set of toolchain tools for each system. In general, that means the last xcode that Apple provided for each system.



(There are a couple of exceptions, where the latest xcode provided an SDK that was one OS version newer than the system version. In those systems, to have a matching SDK to the system, Ryan has held back the xcode version to the last that matched the system. This is really not ideal, and the better option is to use the newest supported xcode with an added SDK that matches the system - but that has not as yet been automated and so we are stuck with this discrepancy for now.)


So I'd say that if you have an unusual use case, where you want to run an old xcode version on a specific system for your own reasons -- that is not something that MacPorts should be modified to start supporting.


Ken


Sent from my iPhone

> On Dec 25, 2024, at 9:47 AM, Gagan Sidhu via macports-dev <macports-dev at lists.macports.org> wrote:
> 
> i think it’s an old and unneeded workaround for newer clangs. could someone look into this?
> 
> i know that it’s not needed for newer clangs and, if anything, will frustrate any potential users from staying with our package manager.
> 
> in my experience i’ve found this macro to be more of a hindrance than a positive. i would appreciate a resolution to improve our competitiveness in this space.
> 
> Thanks,
> Gagan
> 
>> On Dec 25, 2024, at 10:45 AM, Ryan Carsten Schmidt <ryandesign at macports.org> wrote:
>> 
>> On Dec 25, 2024, at 11:40, Gagan Sidhu wrote:
>>> 
>>> it’s the scripts or macro check for xcrun are causing a problem:
>>>> 
>>>> vms-Mac-2:MacOS vm$ cat /opt/local/bin/clang++-mp-17
>>>> #!/bin/bash
>>>> 
>>>> if [ -x /usr/bin/xcrun ] ; then
>>>>  exec /usr/bin/xcrun /opt/local/libexec/llvm-17/bin/clang++ "${@}"
>>>> else
>>>>  exec /opt/local/libexec/llvm-17/bin/clang++ "${@}"
>>>> fi
>> 
>> Oh. I didn't know our clang was a wrapper script that did this.
>> 
>> 
>