/usr/bin/clang++ cannot compile anything when trying to compile as x86_64 on a current arm system against the MacOSX10.13.sdk (but macports-clang does work)

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

[kencu (Ken)]

so clang has changed the way it looks for c++ headers.

It looks here now:

<SDK>/usr/include/c++/v1

but the 10.13 SDK doesn't have that path, it has this:

<SDK>/usr/include/c++/4.2.1

so that is easy to solve with a trivial symlink:

sudo ln -s 4.2.1 v1

% ls -la
total 0
drwxr-xr-x@   4 root  wheel   128  9 Jun 13:03 .
drwxr-xr-x@ 267 root  wheel  8544 26 Mar  2018 ..
drwxr-xr-x@  58 root  wheel  1856  6 Oct  2017 4.2.1
lrwxr-xr-x    1 root  wheel     5  9 Jun 13:03 v1 -> 4.2.1

and that gets you farther, but still no bueno:

% /usr/bin/clang++  -pipe -Os -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk hello.cpp 
Undefined symbols for architecture x86_64:
  "std::ios_base::Init::Init()", referenced from:
      __GLOBAL__sub_I_hello.cpp in hello-3a43aa.o
  "std::ios_base::Init::~Init()", referenced from:
      __GLOBAL__sub_I_hello.cpp in hello-3a43aa.o
  "std::basic_ostream<char, std::char_traits<char>>& std::__ostream_insert<char, std::char_traits<char>>(std::basic_ostream<char, std::char_traits<char>>&, char const*, long)", referenced from:
      _main in hello-3a43aa.o
  "std::cout", referenced from:
      _main in hello-3a43aa.o
ld: symbol(s) not found for architecture x86_64

and exactly why the linker can't find the symbols is not yet clear...

% /usr/bin/clang++  -v -Wl,-v -pipe -Os -arch x86_64 -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
 "/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/include/c++/v1 -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-f75c30.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:
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/usr/include/c++/v1
 /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.
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -platform_version macos 10.13.0 10.13 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -Os -o a.out -v /var/folders/97/nn3swcb52bg003_4bctdbyd80000gn/T/hello-f75c30.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.osx.a
@(#)PROGRAM:ld PROJECT:ld-1053.12
BUILD 10:14:46 Mar 29 2024
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.3.2.2)
Library search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/usr/lib
Framework search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/System/Library/Frameworks
Undefined symbols for architecture x86_64:
  "std::ios_base::Init::Init()", referenced from:
      __GLOBAL__sub_I_hello.cpp in hello-f75c30.o
  "std::ios_base::Init::~Init()", referenced from:
      __GLOBAL__sub_I_hello.cpp in hello-f75c30.o
  "std::basic_ostream<char, std::char_traits<char>>& std::__ostream_insert<char, std::char_traits<char>>(std::basic_ostream<char, std::char_traits<char>>&, char const*, long)", referenced from:
      _main in hello-f75c30.o
  "std::cout", referenced from:
      _main in hello-f75c30.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

and now I just have to remind myself why we are trying to bash our heads in building against the 10.13 SDK again ...

[lukaso (Lukas Oberhuber)]

Thanks for looking into this. The really odd thing is that it works fine on arm64, just not on rosetta.

and now I just have to remind myself why we are trying to bash our heads in building against the 10.13 SDK again ...

I know, this is a huge pain... The reason is to be able to compile GIMP for x86_64 now that CI providers are sunsetting their intel Macs. It's definitely feeling like this approach is running against a brick wall, so finding a hosted old mac might be the only path. Although, right now, the more likely is that GIMP stops supporting Intel Macs.

[kencu (Ken)]

But why are you using the 10.13 SDK?

The current latest macOS SDK supports Intel, as above comment:15

Oh, never mind, I remember why -- because you would like to deploy back to 10.13, and to do that most reliably, you would build against the 10.13 SDK. That is why.

[kencu (Ken)]

OK, well forcing it to also link against libstdc++.dylib finds the missing symbols, stupidly:

% /usr/bin/clang++  -v -Wl,-v -pipe -Os -target x86_64-apple-darwin17 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk hello.cpp -Wl,-lstdc++.6

and produces a working binary, although a Frankenstein thing, linked against libstd++ and libc++:

 % ./a.out
Hello World!

% otool -L a.out
a.out:
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

So now we just need to sort out why those missing symbols are not in libc++.dylib (apparently) any more. Did they get moved to some other library I wonder?

[kencu (Ken)]

So it works to build an x86_64 binary building against the current SDK and setting the deployment target to 10.13, but not when building against the 10.13 SDK -- it is not finding the symbols in the libc++.tbd file in the 10.13 SDK, for whatever reason I don't current get.

% MACOSX_DEPLOYMENT_TARGET=10.13 /usr/bin/clang++  -v -Wl,-v -pipe -Os -target x86_64-apple-darwin17 hello.cpp
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: x86_64-apple-darwin17
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.13.0 -Wundef-prefix=TARGET_OS_ -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=14.5 -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 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I/usr/local/include -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1 -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/include -internal-externc-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.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-38a142.o -x c++ hello.cpp
clang -cc1 version 15.0.0 (clang-1500.3.9.4) default target arm64-apple-darwin23.5.0
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -platform_version macos 10.13.0 14.5 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -Os -o a.out -L/usr/local/lib -v /var/folders/97/nn3swcb52bg003_4bctdbyd80000gn/T/hello-38a142.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.osx.a
@(#)PROGRAM:ld PROJECT:ld-1053.12
BUILD 10:15:51 Mar 29 2024
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.3.2.2)
Library search paths:
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/swift
Framework search paths:
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks

% MACOSX_DEPLOYMENT_TARGET=10.13 /usr/bin/clang++  -v -Wl,-v -pipe -Os -target x86_64-apple-darwin17 -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-darwin17
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.13.0 -Wundef-prefix=TARGET_OS_ -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 -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/include/c++/v1 -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-e3c9c1.o -x c++ hello.cpp
clang -cc1 version 15.0.0 (clang-1500.3.9.4) default target arm64-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:
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/usr/include/c++/v1
 /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.
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -platform_version macos 10.13.0 10.13.0 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -Os -o a.out -v /var/folders/97/nn3swcb52bg003_4bctdbyd80000gn/T/hello-e3c9c1.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.osx.a
@(#)PROGRAM:ld PROJECT:ld-1053.12
BUILD 10:15:51 Mar 29 2024
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.3.2.2)
Library search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/usr/lib
Framework search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk/System/Library/Frameworks
Undefined symbols for architecture x86_64:
  "std::ios_base::Init::Init()", referenced from:
      __GLOBAL__sub_I_hello.cpp in hello-e3c9c1.o
  "std::ios_base::Init::~Init()", referenced from:
      __GLOBAL__sub_I_hello.cpp in hello-e3c9c1.o
  "std::basic_ostream<char, std::char_traits<char>>& std::__ostream_insert<char, std::char_traits<char>>(std::basic_ostream<char, std::char_traits<char>>&, char const*, long)", referenced from:
      _main in hello-e3c9c1.o
  "std::cout", referenced from:
      _main in hello-e3c9c1.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[ryandesign (Ryan Carsten Schmidt)]

Replying to lukaso:

The really odd thing is that it works fine on arm64, just not on rosetta.

You're claiming you're able to build an arm64 macOS executable using the 10.13 SDK? That should be impossible. macOS 11 and its SDK are the first to have any arm64 support.

The reason is to be able to compile GIMP for x86_64 now that CI providers are sunsetting their intel Macs. It's definitely feeling like this approach is running against a brick wall, so finding a hosted old mac might be the only path. Although, right now, the more likely is that GIMP stops supporting Intel Macs.

There are tons of old Intel Macs available for sale near me that would work fine as a 10.13 build server for your needs. I would be surprised if you can't find a suitable Mac mini for under $200.

[kencu (Ken)]

good news for you: macports-clang works, and the deployment target is set to 10.13 as desired (I checked the verbose build).

It doesn't even need the v1 symlink, which I removed now.

This is on an arm64 Mac, either with a rosetta shell or not.

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

#include <iostream>

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

% /opt/local/bin/clang++-mp-17 -pipe -Os -target x86_64-apple-darwin17 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk hello.cpp 

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

% ./a.out
Hello World!

% otool -l a.out
...
Load command 9
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.13
      sdk 10.13

[kencu (Ken)]

so you should be able to do your thing with the SDK and the deployment target set to 10.13, so long as you blacklist /usr/bin/clang in all your builds.

That is -- not terribly hard to do. You can set up custom compilers in macports.conf. But OOTH, it's an extra step too, and you need to keep your wits about you.

There will no doubt be some bootstrapping headaches I haven't begun to address...those may prove overwhelming or even insurmountable to automate...what you would do manually is install clang-17 first, then set your deployment target and sdk and arrange to avoid “clang” in macports.conf, after clang-17 is installed. You may need to rebuild some clang dep as 10.13 if you need it for gimp.

I still say that a VM or a dedicated machine is your better option, but indeed, as is usual with MacPorts, with perseverance there is generally a way.

[lukaso (Lukas Oberhuber)]

@kencu and @ryandesign, thanks so much for your help. Finally got to this.

My workaround ended up being to compile against the current SDK since cmake-bootstrap is a build time dependency. I was actually facing this bug: ​https://trac.macports.org/ticket/66953 which affects cmake-bootstrap as well as cmake.

My workaround is to do this:

  sed -i -e 's/buildfromsource always/buildfromsource ifneeded/g' ${PREFIX}/etc/macports/macports.conf
  sed -i -e 's/macosx_deployment_target/#macosx_deployment_target/g' ${PREFIX}/etc/macports/macports.conf
  sed -i -e 's/macosx_sdk_version/#macosx_sdk_version/g' ${PREFIX}/etc/macports/macports.conf
  (
    # temporarily unset deployment targets since cmake does not build with 10.13 SDK
    # and we don't really care since only used at build time
    # Can be removed once https://trac.macports.org/ticket/66953 is fixed
    unset MACOSX_DEPLOYMENT_TARGET
    unset SDKROOT
    echo "clean cmake-bootstrap****"
    port_clean_and_install cmake-bootstrap
  )
  sed -i -e 's/buildfromsource ifneeded/buildfromsource always/g' ${PREFIX}/etc/macports/macports.conf
  sed -i -e 's/#macosx_deployment_target/macosx_deployment_target/g' ${PREFIX}/etc/macports/macports.conf
  sed -i -e 's/#macosx_sdk_version/macosx_sdk_version/g' ${PREFIX}/etc/macports/macports.conf

For whatever reason, cmake-bootstrap wasn't being built as a dependency when I was building on true x86_64 so this appeared to be a rosetta 2 issue to me.

I apologize as I should have realized this was the case, and that I already had a workaround which I was using for cmake.

[lukaso (Lukas Oberhuber)]

That is -- not terribly hard to do. You can set up custom compilers in macports.conf. But OOTH, it's an extra step too, and you need to keep your wits about you.

I can't find any documentation on how to set compiler.blacklist or a default compiler in macports.conf. (cmake-bootstrap isn't the only port that is breaking on 10.13 SDK). How is this done?