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} } {

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #72091.

[Gcenx]

You can remove game-porting-toolkit as I’d removed that in [53bbcfac6c32320ee4421989c809a7497077a47b/macports-ports]

[ryandesign (Ryan Carsten Schmidt)]

This caused a build failure for a user building libgcc15; see #72964.

[Gcenx]

Again please remove game-porting-toolkit from this as if removed the Xcode check months ago and lined to the relevant commit, it’s actually listed twice for some reason.

[reneeotten (Renee Otten)]

I admit that I don't fully understand the reason for using configure.ldflags-append -Wl,-ld_classic, but presumably the ports listed here failed to build at some point without... In any case, doing this for the ffmpeg* ports causes dependents now to fail with errors like:

ld: chained fixups, seg_count exceeds number of segments in '/opt/local/libexec/ffmpeg7/lib/libswresample.5.3.100.dylib'

Removing the code that uses the pre-XCode-15 linker from the Portfiles resolves that issue, and the ports build fine on the CI system (which are the macOS versions that were presumably affected) and locally on macOS Tahoe (cf. ​https://github.com/macports/macports-ports/pull/29417). So are we sure that any of this is still needed and can we not just remove it instead? To me it seems like reasonable for us to assume that end-user will have updated to the latest XCode version supported on their system (or ask/require them to do so).