Opened 12 days ago
Last modified 11 days ago
#69812 new defect
cmake-bootstrap @3.9.6 does not compile under rosetta2
Reported by: | lukaso (Lukas Oberhuber) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | mascguy (Christopher Nielsen) | |
Port: | cmake-bootstrap |
Description
---> 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
Attachments (2)
Change History (12)
Changed 12 days ago by lukaso (Lukas Oberhuber)
Attachment: | cmake_bootstrap_main.log added |
---|
Changed 12 days ago by lukaso (Lukas Oberhuber)
Attachment: | cmake_bootstrap.log added |
---|
Configure failure
comment:1 Changed 12 days ago by 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.
comment:2 follow-up: 4 Changed 12 days ago by 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
comment:3 Changed 12 days ago by lukaso (Lukas Oberhuber)
I should add, I've downloaded the 10.13 sdk.
comment:4 Changed 12 days ago by 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.
comment:5 follow-up: 7 Changed 12 days ago by 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.
comment:6 Changed 11 days ago by 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
comment:7 Changed 11 days ago by 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.
comment:8 follow-up: 10 Changed 11 days ago by 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.
comment:9 Changed 11 days ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
comment:10 Changed 11 days ago by 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.
main build log