cmake-bootstrap @3.9.6 does not compile under rosetta2

[lukaso (Lukas Oberhuber)]

--->  Fetching distfiles for cmake-bootstrap
--->  Attempting to fetch cmake-3.9.6.tar.gz from https://distfiles.macports.org/cmake
--->  Verifying checksums for cmake-bootstrap
--->  Extracting cmake-bootstrap
--->  Applying patches to cmake-bootstrap
--->  Configuring cmake-bootstrap
Error: Failed to configure cmake-bootstrap: configure failure: command execution failed
Error: See /Users/lukasoberhuber/macports-gimp3-x86_64/var/macports/logs/_Users_lukasoberhuber_macports-gimp3-x86_64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port curl failed

[lukaso (Lukas Oberhuber)]

main build log

[lukaso (Lukas Oberhuber)]

Configure failure

[ryandesign (Ryan Carsten Schmidt)]

What does "under rosetta2" mean here? The log looks like you're on an Intel machine running macOS 14 compiling for x86_64. Are you saying you're actually on an arm64 machine? If so, what steps have you taken that are making it behave like an Intel machine?

While I'm not sure exactly what part of the cmake log is relevant here, I see it has lots of instances of:

/Users/lukasoberhuber/macports-gimp3-x86_64/var/macports/build/_Users_lukasoberhuber_macports-gimp3-x86_64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/bootstrap: line 677: : command not found

What is around line 677 of that file? It seems like some command is supposed to be on that line but isn't.

[lukaso (Lukas Oberhuber)]

I've run this in an x86_64 terminal window which I created using arch -x86_64 /bin/zsh. So yes, this is an Arm64 machine.

This is line 677:

  "${COMPILER}" ${FLAGS} "${TESTFILE}" -o "${TMPFILE}"

in this function:

cmake_try_run ()
{
  COMPILER=$1
  FLAGS=$2
  TESTFILE=$3
  if [ ! -f "${TESTFILE}" ]; then
    echo "Test file ${TESTFILE} missing. Please verify your CMake source tree."
    exit 4
  fi
  TMPFILE=`cmake_tmp_file`
  echo "Try: ${COMPILER}"
  echo "Line: ${COMPILER} ${FLAGS} ${TESTFILE} -o ${TMPFILE}"
  echo "----------  file   -----------------------"
  cat "${TESTFILE}"
  echo "------------------------------------------"
  "${COMPILER}" ${FLAGS} "${TESTFILE}" -o "${TMPFILE}"
  RES=$?
  if [ "${RES}" -ne "0" ]; then
    echo "Test failed to compile"
    return 1
  fi
  if [ ! -f "${TMPFILE}" ] && [ ! -f "${TMPFILE}.exe" ]; then
    echo "Test failed to produce executable"
    return 2
  fi
  ./${TMPFILE}
  RES=$?
  rm -f "${TMPFILE}"
  if [ "${RES}" -ne "0" ]; then
    echo "Test produced non-zero return code"
    return 3
  fi
  echo "Test succeeded"
  return 0
}

I also checked the compiler line it claimed it couldn't run, and it worked:

/usr/bin/clang -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -arch x86_64 -std=gnu11

[lukaso (Lukas Oberhuber)]

I should add, I've downloaded the 10.13 sdk.

[ryandesign (Ryan Carsten Schmidt)]

Replying to lukaso:

I've run this in an x86_64 terminal window which I created using arch -x86_64 /bin/zsh. So yes, this is an Arm64 machine.

Then the next question is: why are you doing this? This is not a normal way to use MacPorts.

I also checked the compiler line it claimed it couldn't run, and it worked:

/usr/bin/clang -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -arch x86_64 -std=gnu11

Right, it works if you use /usr/bin/clang as the compiler. The failing tests are not using /usr/bin/clang as the compiler; they're using the empty string.

[lukaso (Lukas Oberhuber)]

Then the next question is: why are you doing this? This is not a normal way to use MacPorts.

@ryandesign a very good point and question.

I use Macports to build the GIMP release packages. Basically all the dependencies and GIMP itself.

Circle CI where we do our builds, has deprecated intel runners with an M1+ only runner approach (claiming M1 boxes build intel executables better). So from June 29th, 2024 I won't have an intel build machine. Which leaves me with Rosetta2 as my only option (or stop supporting Intel).

Other options such as cross compiling seem even further out of reach. I don't suppose Macports supports this?

I think there are problems with quite a few of the dependencies in supporting rosetta 2, for example jemalloc had problems in the past.

But I do want to keep supporting Intel and 10.13 if possible.

[kencu (Ken)]

there should be a way to make this work, with some shenanigans likely.

the problem is not the C compiler line you quoted, but the CXX compiler is not finding the sysroot.

see if you can open an x86_64 terminal as you do, and then compile a few simple test cxx files and see what happens

/usr/bin/clang++ -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -arch x86_64

[ryandesign (Ryan Carsten Schmidt)]

Replying to lukaso:

Other options such as cross compiling seem even further out of reach. I don't suppose Macports supports this?

If you mean compiling for macOS on Linux or another OS, then no. If you mean comping for one macOS version on another macOS version, or for one macOS architecture from another macOS architecture, then yes, with the caveat that it is not well tested and there are therefore frequent problems.

But I do want to keep supporting Intel and 10.13 if possible.

The simplest way to do so would be to perform the builds on a machine that runs macOS 10.13. While not available on public CI systems anymore, you can run 10.13 on an older Intel Mac that you own, or perhaps in a virtual machine on a newer Mac.

[lukaso (Lukas Oberhuber)]

If you mean comping for one macOS version on another macOS version, or for one macOS architecture from another macOS architecture, then yes, with the caveat that it is not well tested and there are therefore frequent problems.

How is this done? I might as well try it.

The simplest way to do so would be to perform the builds on a machine that runs macOS 10.13.

I've tried to find ways of doing this. But it's not OK for our builds to be on a machine under my desk. How does Macports do this? I suppose, if I had a VM that was properly hosted, I could support even older MacOS versions.

[ryandesign (Ryan Carsten Schmidt)]

Replying to lukaso:

If you mean comping for one macOS version on another macOS version, or for one macOS architecture from another macOS architecture, then yes, with the caveat that it is not well tested and there are therefore frequent problems.

How is this done? I might as well try it.

Building for a different OS version, you're already doing by setting macosx_deployment_target in macports.conf I presume. While Apple would like us to believe that we can build for older OS versions using the latest SDK, it looks like you're also specifying the older 10.13 SDK by setting macosx_sdk_version in macports.conf.

Building for another arch is done by changing build_arch (for non-universal builds) and universal_archs (for universal builds) in macports.conf.

And I agree with Ken that what you're doing using Rosetta 2 should work but I don't think anybody has tested it before.

The simplest way to do so would be to perform the builds on a machine that runs macOS 10.13.

I've tried to find ways of doing this. But it's not OK for our builds to be on a machine under my desk. How does Macports do this? I suppose, if I had a VM that was properly hosted, I could support even older MacOS versions.

I run ​https://build.macports.org from three Xserves running VMware ESXi with VMs for each OS version.