/usr/bin/clang++ cannot compile anything when trying to compile as x86_64 on a current arm system against the MacOSX10.13.sdk

[lukaso (Lukas Oberhuber)]

the title of this was:

cmake-bootstrap @3.9.6 does not compile under rosetta2

--->  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.

[lukaso (Lukas Oberhuber)]

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

I ran this in an arch x86_64 terminal and got this:

$ /usr/bin/clang++ -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -arch x86_64 temp.cpp
temp.cpp:4:11: fatal error: 'iostream.h' file not found
# include <iostream.h>
          ^~~~~~~~~~~~
1 error generated.

[lukaso (Lukas Oberhuber)]

This was using the contents of the failed test from the log.

[lukaso (Lukas Oberhuber)]

This would be what it might have been trying to run (if it had the executable):

$ /usr/bin/clang++ -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -arch x86_64 -qlanglvl=extended -DTEST1 temp.cxx -o
clang: error: argument to '-o' is missing (expected 1 value)
clang: error: unknown argument: '-qlanglvl=extended'

BTW: results are the same in rosetta as in standard. So the bug seems to be in finding the excutable.

[ryandesign (Ryan Carsten Schmidt)]

What executable? In comment:11 it says it can't find the <iostream.h> header, which is probably correct, since the header is ​called <iostream> in modern systems. We'd need to see the contents of temp.cpp but maybe its purpose is to discover what the name of the iostream header is on your system.

And in comment:13 it gives errors about an argument that is definitely not known to clang, so temp.cxx is probably designed to test whether the compiler supports this flag and it has correctly determined that it does not.

So these errors are not bugs; these errors are the configure script working as intended.

[kencu (Ken)]

I'm advising you to start WAY more simply.

See if you can figure out how to compile ANYTHING on that system, anything at all.

On my arm64 system, this works fine:

% arch -x86_64 /bin/zsh

% uname -a
Darwin Kens-MBP 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 x86_64

% cat hello.cpp
// Your First C++ Program

#include <iostream>

int main() {
    std::cout << "Hello World!";
    return 0;
}

% /usr/bin/clang++ -pipe -Os hello.cpp

% file a.out
a.out: Mach-O 64-bit executable x86_64

% ./a.out
Hello World!

does that work for you?

My suspicion is that your problem is coming from specifying the SDK exactly -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk but that SDK doesn't actually translate to a real SDK. However, you'd have to check that yourself.

[lukaso (Lukas Oberhuber)]

Yes, this works fine.

If you look at cmake_bootstrap.log you'll see that the clang++ executable is missing from the command.

This is a good run on arm64 (not the same test, but you get the idea):

Try: /usr/bin/clang++
Line: /usr/bin/clang++ -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk -arch arm64 -std=gnu++14  -DTEST_KWSYS_CXX_HAS_EXT_STDIO_FILEBUF_H /Users/lukasoberhuber/macports-gimp3-arm64/var/macports/build/_Users_lukasoberhuber_macports-gimp3-arm64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Source/kwsys/kwsysPlatformTestsCXX.cxx -o cmake_bootstrap_41862_test

And this is a bad run on rosetta x86_64 (note the Try: line).

Try: 
Line:  -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -arch x86_64 -qlanglvl=extended -DTEST1 cmake_bootstrap_18180_test.cxx -o cmake_bootstrap_18180_test

[kencu (Ken)]

so PLEASE just try this in an x86_64 terminal:

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

% cat hello.cpp
// Your First C++ Program

#include <iostream>

int main() {
    std::cout << "Hello World!";
    return 0;
}

[kencu (Ken)]

OK -- I install the 10.13 SDK, and get this too...

% /usr/bin/clang++ -pipe -Os -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk hello.cpp  
hello.cpp:3:10: fatal error: 'iostream' file not found
#include <iostream>
         ^~~~~~~~~~
1 error generated.


% /usr/bin/clang++ -v -pipe -Os -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk hello.cpp 
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: x86_64-apple-darwin23.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/usr/include/c++/v1"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1"
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.13.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -emit-obj --mrelax-relocations -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name hello.cpp -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-strict-return -ffp-contract=on -fno-rounding-math -funwind-tables=2 -target-sdk-version=10.13 -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -target-cpu penryn -tune-cpu generic -debugger-tuning=lldb -target-linker-version 1053.12 -v -fcoverage-compilation-dir=/Users/cunningh -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/usr/local/include -internal-isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/usr/include -internal-externc-isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -Os -Wno-reorder-init-list -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-final-dtor-non-final-class -Wno-extra-semi-stmt -Wno-misleading-indentation -Wno-quoted-include-in-framework-header -Wno-implicit-fallthrough -Wno-enum-enum-conversion -Wno-enum-float-conversion -Wno-elaborated-enum-base -Wno-reserved-identifier -Wno-gnu-folding-constant -fdeprecated-macro -fdebug-compilation-dir=/Users/cunningh -ferror-limit 19 -stack-protector 1 -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fno-cxx-modules -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcommon -fcolor-diagnostics -vectorize-loops -vectorize-slp -clang-vendor-feature=+disableNonDependentMemberExprInCurrentInstantiation -fno-odr-hash-protocols -clang-vendor-feature=+enableAggressiveVLAFolding -clang-vendor-feature=+revert09abecef7bbf -clang-vendor-feature=+thisNoAlignAttr -clang-vendor-feature=+thisNoNullAttr -mllvm -disable-aligned-alloc-awareness=1 -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/97/nn3swcb52bg003_4bctdbyd80000gn/T/hello-42630f.o -x c++ hello.cpp
clang -cc1 version 15.0.0 (clang-1500.3.9.4) default target x86_64-apple-darwin23.5.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/System/Library/Frameworks (framework directory)
End of search list.
hello.cpp:3:10: fatal error: 'iostream' file not found
#include <iostream>
         ^~~~~~~~~~
1 error generated.

so this has nothing to do with cmake-bootstrap, or MacPorts.

The compiler simply doesn't work this way, against this SDK. Let's see if there is some way to make it work.... I will try some things. No promises.

[kencu (Ken)]

this doesn't work either, no surprise:

% SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk /usr/bin/clang++ -v -pipe -Os hello.cpp

[kencu (Ken)]

next thing to do would be to try some of the newer (or older) macports-clang compilers and see if those might work.