During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?

Peter Serocka peserocka at gmail.com
Thu Apr 14 18:56:35 UTC 2022

> On Apr 14, 2022, at 14:10, chilli.namesake at gmail.com wrote:
> Thinking more about upgrading, maybe there's an Xcode version issue? MacPorts requires Xcode's command line tools. Though a newer version of macOS can run older and outdated versions of Xcode, after upgrading the OS, the user will often find Xcode greyed out with the circle with the line through it. Upgrading macOS didn't used to do this, but it apparently does now. There are steps (or tricks) available now to get older Xcode versions working with a newer mismatched macOS version. But I bet that's why port is choking after upgrade: maybe port still works, but the upgrade broke Xcode, so port chokes. A wild guess.

Xcode version mismatch issues do exist in some situations, and I have been dealing with those; but my point here is that the port command itself refuses to do any further work after a major macOS upgrade. It chokes quite early, inside proc mportinit found in <prefix>/libexec/macports/lib/macports1.0/macports.tclmacports.tcl
and the error message is:

Error: Current platform "darwin 19" does not match expected platform "darwin 18"
Error: If you upgraded your OS, please follow the migration instructions: https://trac.macports.org/wiki/Migration
OS platform mismatch
    while executing
"mportinit ui_options global_options global_variations"
Error: /opt/macports18/bin/port: Failed to initialize MacPorts, OS platform mismatch

Which prevents further upgrades or installs in the existing tree. 

(Sadly one can't even run a "port installed" or a "port requested" at this point, in case one missed to capture these for reference before the macOS upgrade. Just noted as an aside; as this will happen with either prefix, default or custom.)

More information about the macports-users mailing list