Incorrect conditions for making decisions based on Xcode or Xcode command line tools version

[ryandesign (Ryan Carsten Schmidt)]

Multiple ports and the mpi 1.0 portgroup use code such as this to decide whether to use the pre-Xcode-15 linker:

platform darwin {
    if {([vercmp ${xcodeversion} >= 15]) || ([vercmp ${xcodecltversion} >= 15])} {
        configure.ldflags-append -Wl,-ld_classic
    }
}

This is wrong because it does not take into consideration whether Xcode or the Xcode command line tools will be used for the build.

• If the user only has the Xcode command line tools installed, then the Xcode command line tools will be used.
• If the user only has Xcode installed, then Xcode will be used.
• If the user has both Xcode and the Xcode command line tools installed, then Xcode will be used if use_xcode yes is set, otherwise the Xcode command line tools will be used.

The current code works fine if the user has the same version of Xcode and the Xcode command line tools but that is not necessarily the case. Even two of the GitHub Actions CI runners are currently configured with mismatched Xcode and Xcode command line tools versions; see #69668.

I found these affected ports: gcc-devel, gcc10-bootstrap, gcc11, gcc12, gcc13, zig, scip, sundials5, ffmpeg-devel, ffmpeg, ffmpeg6, basix, root6. gcc8, gcc9, and gcc10 use a similarly incorrect check for Xcode or CLT version 12.5.

I don't know what the correct code would be but once it's figured out what it is it can be fixed in all the places.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

I don't know what the correct code would be

How about:

if {[vercmp [expr {${use_xcode} || ${xcodecltversion} eq {none} ? ${xcodeversion} : ${xcodecltversion}}] >= 15]} {

[cjones051073 (Chris Jones)]

It is also incorrect now that these are open ended, as the issue was eventually fixed by apple in a subsequent Xcode/CLT release (not known at the time they where added).

So if we want to keep these that should also be taken into account now.

[ryandesign (Ryan Carsten Schmidt)]

Replying to cjones051073:

fixed by apple in a subsequent Xcode/CLT release

Which one?

[cjones051073 (Chris Jones)]

Replying to ryandesign:

Replying to cjones051073:

fixed by apple in a subsequent Xcode/CLT release

Which one?

If I knew I would have said ;)

[cjones051073 (Chris Jones)]

We could of course just remove them all, which would amount to an implicit assumption that anyway using one of the affected Xcode versions has since updated...

[ryandesign (Ryan Carsten Schmidt)]

I don't think removing the code is a good idea. Our GitHub Actions CI runners have not, for example, been updated to fixed Xcode versions, and while we could and should update them, there is no guarantee that users have updated. We do not want to expend more time re-investigating this problem with such users. polyml, for example, is ​a port that failed to build and would be fixed by applying this workaround, but I did not do so yet since the then-known workaround was wrong, and I filed this ticket to discover the correct workaround that can then be applied to polyml and all other affected ports or placed into a common portgroup.

[ryandesign (Ryan Carsten Schmidt)]

We have Xcode 15.2 on the macOS 14 buildbot workers and polyml failed to build there. If you have a newer Xcode on macOS 14, can you try building polyml and let us know the result?

[ryandesign (Ryan Carsten Schmidt)]

Newly-added game-porting-toolkit is also affected, using the more convoluted:

set clt150   [expr { ${xcodeversion} eq "none" && ${xcodecltversion} ne "none" && [vercmp ${xcodecltversion} >= "15.0"] } ]
set xcode150 [expr { ${xcodeversion} ne "none" && [vercmp ${xcodeversion} >= "15.0"] } ]
if { ${clt150} || ${xcode150} } {