Opened 2 years ago

Closed 12 months ago

#66427 closed defect (worksforme)

migrating macports to M1 fails to build cmake

Reported by: jmgurney (John-Mark Gurney) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: michaelld (Michael Dickens)
Port: cmake

Description (last modified by ryandesign (Ryan Carsten Schmidt))

I am migrating my system from an old Intel MBP to a new M1 Pro based MBP (13.0.1 (22A400)).

I am following the direction here: wiki:Migration to rebuild the ports.

The issue I'm running into is that cmake is being built as a dependency, but the +universal variant is being built. This means that cmake is attempting to build for x86_64, and as part of the configure process, tries to run an x86_64 binary but this fails. I have not installed Rosetta (not sure if this would fix the issue or not), as I'm trying to make sure I get as many native binaries as possible before breaking down and using it.

The output from restore_ports.tcl:

--->  Computing dependencies for cmake
--->  Fetching archive for cmake
--->  Attempting to fetch cmake-3.24.3_0+universal.darwin_22.arm64-x86_64.tbz2 from http://mirror.fcix.net/macports/packages/cmake
--->  Attempting to fetch cmake-3.24.3_0+universal.darwin_22.arm64-x86_64.tbz2 from https://packages.macports.org/cmake
--->  Attempting to fetch cmake-3.24.3_0+universal.darwin_22.arm64-x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/cmake
--->  Configuring cmake
Error: Failed to configure cmake: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/main.log for details.
upgrade tiff failed
    while executing
"macports::_upgrade_mport_deps $mport $target"
    (procedure "mportexec" line 46)
    invoked from within
"mportexec $workername $install_target"
Unable to execute target 'install' for port 'qt4-mac': upgrade tiff failed
    while executing
"install_ports $operationList"
    (file "./restore_ports.tcl" line 299)

Attached are the relevant logs as well.

I'd expect that either cmake not support a universal variant, or the migration to not attempt to install universal variants if they don't work.

I did notice a similar bug in #66213 and I also noticed that the build systems don't actually build/test the universal variant of ports: https://build.macports.org/builders/ports-12_arm64-builder/builds/73986/steps/install-port/logs/stdio which explains why this failure was not caught.

Attachments (2)

main.log (744.9 KB) - added by jmgurney (John-Mark Gurney) 2 years ago.
cmake main.log
cmake_bootstrap.log (93.2 KB) - added by jmgurney (John-Mark Gurney) 2 years ago.
cmake configure failure log, showing failure to run x86_64 binary

Download all attachments as: .zip

Change History (13)

Changed 2 years ago by jmgurney (John-Mark Gurney)

Attachment: main.log added

cmake main.log

Changed 2 years ago by jmgurney (John-Mark Gurney)

Attachment: cmake_bootstrap.log added

cmake configure failure log, showing failure to run x86_64 binary

comment:1 Changed 2 years ago by kencu (Ken)

This is both a feature and a curse of the way MacPorts handles universal ports.

For cmake, if you install it separately, like this:

sudo port -v install cmake

before you run the restore script, at least that one will install without universal, and will then be ignored by the restore script as it will be seen to be already installed.

(I am curious what else you have on your list that is calling for cmake to be installed as universal though -- you might run into troubles with more universal builds still -- perhaps you can spot the issue in your list of ports.)

comment:2 Changed 2 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Port: cmake added

comment:3 Changed 2 years ago by jmgurney (John-Mark Gurney)

I actually had to install cmake earlier so that I could manually build the editor I use, so it's already installed:

$ port installed | grep cmake
  cmake @3.24.3_0 (active)
  cmake-bootstrap @3.9.6_0 (active)

And yet I'm still getting the error.

I still tried it:

$ sudo port -v install cmake
Password:
Error: Requested variants "" do not match those the build was started with: "+universal".
Error: Please use the same variants again, or run 'port clean cmake' first to remove the existing partially completed build.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port cmake failed
$ sudo port clean cmake
--->  Cleaning cmake
$ sudo port -v install cmake
--->  Computing dependencies for cmake.
--->  Cleaning cmake
--->  Removing work directory for cmake
--->  Scanning binaries for linking errors
Could not open /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit: Error opening or reading file (referenced from /opt/local/share/java/android-sdk-macosx/tools/emulator)
Could not open /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation: Error opening or reading file (referenced from /Library/Java/JavaVirtualMachines/openjdk13-bootstrap/Contents/Home/lib/libawt.dylib)
--->  Found 16 broken files, matching files to ports     
--->  Found 2 broken ports, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
 android @23
 openjdk13-bootstrap @13
Continue? [Y/n]: n

and then I tried to run the restore ports script again, and got the same thing.

As for the dependency, it looks like it's from tiff via qt4-mac, but I don't know exactly.

I did a quick peak at which packets are requested to be universal, and neither qt4-mac nor tiff are listed directly.

Is there a way to make cmake NOT be universal? since it clearly breaks when done so, or lie about it being universal, and build only a single platform?

comment:4 Changed 2 years ago by kencu (Ken)

if cmake is installed, Macports will not (should not) request it to be reinstalled +universal unless perhaps it is expressly written on your restore ports script as being universal, in which case I presume you'd remove that.

It actually looks like cmake is installed now, no problem, and your error is now some other thing.

Last edited 2 years ago by kencu (Ken) (previous) (diff)

comment:5 Changed 2 years ago by jmgurney (John-Mark Gurney)

It was not:

$ grep cmake myports.txt.orig 
  cmake @3.22.4_0 (active) requested_variants='' platform='darwin 21' archs='x86_64' date='2022-06-02T11:45:52-0700'

I have not removed a number of ports because trying each one is too time consuming, but things seem to be advancing further. The only one that I dropped that was marked universal was:

  db48 @4.8.30_4+universal (active) requested_variants='+universal' platform='darwin 21' archs='arm64 x86_64' date='2022-06-02T11:54:37-0700'

the rest don't have a variant:

$ diff myports.txt myports.txt.orig  | grep '^>' | grep -v db48 | awk ' { if ($4 ~ /^requested_variants/) print $4; else print $5}' | sort -u
requested_variants=''
requested_variants='+llvm80'
requested_variants='+qt4'
requested_variants='+sql'

(myports.txt.orig was the original one before I started trimming things down, myports.txt is what I'm running now and has been running for a couple hours so far.

I'll try to see which one of the ports is causing the breakage once things complete.

comment:6 Changed 2 years ago by jmroot (Joshua Root)

Cc: michaelld added

Installing Rosetta 2 would fix this failure, at least. Unfortunately cmake does want to run a binary it builds for each architecture, which also makes it impossible to build it arm64+x86_64 on x86_64 hardware.

comment:7 Changed 2 years ago by jmroot (Joshua Root)

BTW, qt4-mac can't build as arm64, so it automatically builds as x86_64 instead, which pulls in universal dependencies.

comment:8 Changed 2 years ago by jmgurney (John-Mark Gurney)

I would be nice if there was a more useful error message/explanation of what is going on. And/or warning that qt4-mac requires rosetta 2 to be installed instead of having users spend a day trying to figure out why things aren't working, etc.

comment:9 Changed 2 years ago by kencu (Ken)

even though qt4-mac is building as x86_64, it should not force an already-installed cmake to be rebuilt as universal.

If it does, then there is an error to fix. So far, you have not demonstrated that is happening.

If you can demonstrate that is happening, I might have something to go on to start a fix.

comment:10 Changed 2 years ago by kencu (Ken)

regarding qt4-mac needing x86_64, it should have given you that message when you tried to install it… although it may not have been clear what the issue was, as macports assumes in it’s logic that an arm machine will have rosetta installed and automatically falls back to x86_64.

That might need some kind of clearer message, agreed.

comment:11 Changed 12 months ago by kencu (Ken)

Resolution: worksforme
Status: newclosed

going to close this as a year-old ticket with no further input.

please reopen if any further issues to troubles with a log.

Note: See TracTickets for help on using tickets.