Opened 4 months ago

Last modified 4 months ago

#70182 new defect

MacPorts 2.9.3 (base): Xcode 15.X causes issues with some OCaml software (segfaults), but MacPorts does not allow Xcode 14.X on Sonoma

Reported by: MSoegtropIMC Owned by:
Priority: Normal Milestone:
Component: base Version: 2.9.3
Keywords: sonoma Cc:
Port:

Description

I am maintaining the multi platform distribution of an interactive proof assistant (Coq Platform) and I am using MacPorts to install common libraries (via opam).

For yet unknown reasons, when OCaml and Coq are compiled with XCode 15.X - or any MacPorts supplied clang using the framework from XCode 15.X, Coq segfaults in rare cases. With XCode 14.3.1 and pretty much all previous versions of XCode there is no such problem (Coq has a fairly broad user base compiling from sources, so there is good evidence for this).

So I would like to use Xcode 14.3.1, but this conflicts with the settings in /opt/local/libexec/macports/lib/port1.0/portutil.tcl - on Sonoma this requires Xcode 15.X.

I wonder where these restrictions come from. Sure Xcode 14 cannot create software targeting the Sonoma version of the SDK, but I doubt that a lot of MacPorts provided software makes use of latest MacOS features. The official Apple docs on MacOS Xcode version compatibility do not mention a lower bound for Xcode on Sonoma:

https://developer.apple.com/support/xcode

Have there been actual problems with compiling MacPorts supplied software with Xcode 14.3.1 on Sonoma?

I patched the files and then get a message:

Warning: The macOS 14 SDK does not appear to be installed. Ports may not build correctly.

even though I export MACOSX_DEPLOYMENT_TARGET=11.0. Why does MacPorts insist on MacOS 14.X as deployment target? Again I have doubts that this makes any difference at all for most MacPorts supplied software packages and very little difference for those where it makes a difference. As the name implies, MacPorts is there to port software written for other OSes to MacOS, which naturally don't use advanced MacOS features. From my desk these restrictions look overly strict and at least for me cause more problems than good.

Change History (7)

comment:1 Changed 4 months ago by jmroot (Joshua Root)

Yes, there have been countless cases where users reported build failures that were due to using an Xcode version too old for their OS.

The SDK and deployment target are separate Portfile options, configure.sdk_version and macosx_deployment_target respectively. Both default to the current OS version. Setting environment variables in your shell won't have any effect.

comment:2 Changed 4 months ago by MSoegtropIMC

Yes, there have been countless cases where users reported build failures that were due to using an Xcode version too old for their OS.

so this is more a general precaution than based on observations with the specific compiler and OS versions mentioned in /opt/local/libexec/macports/lib/port1.0/portutil.tcl ?

Would it be agreeable to allow the latest minor release of the previous major release? Restricting Xcode to just one major release also makes it substantially harder to test if an issue is an Xcode issue. One can still recommend the latest version, but completely disabling it without evidence that this is required is IMHO not a good idea.

comment:3 Changed 4 months ago by MSoegtropIMC

An alternative: would it be thinkable to set the default for configure.sdk_version and macosx_deployment_target?

comment:4 Changed 4 months ago by MSoegtropIMC

Looking at the MacPorts code, I don't think setting configure.sdk_version or macosx_deployment_target in all ports I use would prevent the error.

In /opt/local/libexec/macports/lib/port1.0/portutil.tcl we have:

        switch $macos_version_major {
        :
        :
            14 {
                set min 15.0
                set ok 15.1
                set rec 15.1
            }
        :
        :
} elseif {[vercmp $xcodeversion $min] < 0} {
            ui_error "The installed version of Xcode (${xcodeversion}) is too old to use on the installed OS version. Version $rec or later is recommended on macOS ${macos_version_major}."
            return 1
        }

So as far as I can see, whenever a port needs a toolchain at all, it fails unless one has Xcode 15.X on Sonoma.

comment:5 Changed 4 months ago by ryandesign (Ryan Carsten Schmidt)

You should focus on the problem that Xcode 15 doesn't build this code correctly, rather than trying to make MacPorts use Xcode 14 on a system it wasn't designed for.

comment:6 in reply to:  2 Changed 4 months ago by jmroot (Joshua Root)

Replying to MSoegtropIMC:

so this is more a general precaution than based on observations with the specific compiler and OS versions mentioned in /opt/local/libexec/macports/lib/port1.0/portutil.tcl ?

Every case where the "ok" version is higher than "min" was added because of specific serious bugs that affected port builds.

Looking at the MacPorts code, I don't think setting configure.sdk_version or macosx_deployment_target in all ports I use would prevent the error.

No, that would be in addition to the local modifications you made to base. BTW, if you really want to lie to MacPorts about what version of Xcode you have installed (hopefully understanding and accepting the consequences), you can override xcodeversion in macports.conf. Please just don't report any bugs after doing so.

To allow you to use an older toolchain locally, you could most likely just install older Command Line Tools, as that is what most ports use anyway. You can also install multiple versions of Xcode at the same time and switch between them with xcode-select.

Requiring users (and buildbots) to install an older version of Xcode when building certain ports is not going to be a workable general solution.

comment:7 Changed 4 months ago by MSoegtropIMC

Thank you for the hints, pointers and background info - I will test which method is easiest.

Every case where the "ok" version is higher than "min" was added because of specific serious bugs that affected port builds.

In my experience with compiler stability it is quite common that a X.0 version is less stable than the (X-1).3 version. The .0 versions have new features which introduce new bugs. I don't think it is valid to exclude Xcode 14.3.1 just because 15.0 does not work in some cases. I think it would be reasonable to allow the latest minor version of the previous major version unless there is evidence that this does not work. Since you set the min to 15.0 on Sonoma, I doubt that there is such evidence.

Answering to Ryan:

You should focus on the problem that Xcode 15 doesn't build this code correctly, rather than trying to make MacPorts use Xcode 14 on a system it wasn't designed for.

As I explained the problem is not so easy. We are talking about a program written in a language called Coq, which in turn is written in OCaml which in turn has small parts written in C. It takes several experts to track this down, and for that I need a reliable way to recreate this software. This also requires to make working comparison builds and Macports is in the way here. Besides Coq has a largish user base (it is used in quite a few University courses e.g.) and for advanced users it is recommended to compile from sources. On Sonoma with MacPorts this is currently not possible. What recommendation do you have for these students? Downgrade their MacOS?

Also do you have a reference which states that Xcode 14 is not suitable for Sonoma? The Apple docs I referenced above just say that you need it to compile software which makes uses of Sonoma SDK specific features. As already said, I have doubts that this applies to a lot of MacPorts SW.

Note: See TracTickets for help on using tickets.