10.13 builds failing with latest commits

[nephatrine]

After commit 841dc4242b59fe3e6c12b3f3a4323589be85a9d0 (new architecture handling), my SDK 10.13 builds have started failing. Lots of lines like this during the compiler-rt build where it looks like maybe it's trying to build x86_64 asm for i386 for some reason:

5400.7 [ 16%] Building C object lib/builtins/CMakeFiles/clang_rt.builtins_x86_64h_osx.dir/divsf3.c.o
5400.7 /root/osxcross/build/compiler-rt/compiler-rt/lib/orc/macho_tlv.x86-64.S:20:15: error: register %rbp is only available in 64-bit mode
5400.7         pushq %rbp
5400.7               ^~~~
5400.7 /root/osxcross/build/compiler-rt/compiler-rt/lib/orc/macho_tlv.x86-64.S:21:14: error: register %rsp is only available in 64-bit mode
5400.7         movq %rsp, %rbp
5400.7              ^~~~
5400.7 /root/osxcross/build/compiler-rt/compiler-rt/lib/orc/macho_tlv.x86-64.S:22:20: error: register %rsp is only available in 64-bit mode
5400.7         subq $512, %rsp
5400.7                [ 16%] Building C object lib/builtins/CMakeFiles/clang_rt.builtins_i386_osx.dir/fixsfdi.c.o
5400.7     ^~~~
5400.7 /root/osxcross/build/compiler-rt/compiler-rt/lib/orc/macho_tlv.x86-64.S:23:14: error: register %rbx is only available in 64-bit mode
5400.7         movq %rbx, -8(%rbp)
5400.7              ^~~~

(and many more lines in the same vein)

Using the previous osxcross commit to that everything works fantastically with no changes on my end. I'm building on an x86_64 build box and am not setting ARCHs manually - just letting it build everything it supports for that SDK version which should be x86_64, x86_64h, and i386.

[tpoechtrager]

I am unable to reproduce the issue. Recent versions of Clang fail to build compiler-rt due to the outdated nature of the SDK. With clang 14.0.6, I am able to build compiler-rt without a problem.

What's your exact clang version? Are you using the testing branch or master branch?

[nephatrine]

I'm actually not using a recent version of clang at all - I'm using LLVM 13. Running the master branch. Figured an older LLVM made sense with old SDK version. I can experiment with other LLVM versions.

[tpoechtrager]

Unable to reproduce it with Clang 13.0.1 either.

[100%] Built target RTAsan_dynamic.osx
[100%] Linking CXX shared library ../darwin/libclang_rt.asan_osx_dynamic.dylib
[100%] Built target clang_rt.asan_osx_dynamic
[100%] Built target asan
[100%] Built target compiler-rt

[...]

$ xcrun otool -L /home/thomas/dev/osxcross-master/build/compiler-rt/compiler-rt/build/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib
/home/thomas/dev/osxcross-master/build/compiler-rt/compiler-rt/build/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib (architecture x86_64):
        @rpath/libclang_rt.ubsan_osx_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
        /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 400.8.2)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
/home/thomas/dev/osxcross-master/build/compiler-rt/compiler-rt/build/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib (architecture x86_64h):
        @rpath/libclang_rt.ubsan_osx_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
        /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 400.8.2)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
/home/thomas/dev/osxcross-master/build/compiler-rt/compiler-rt/build/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib (architecture i386):
        @rpath/libclang_rt.ubsan_osx_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
        /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 400.8.2)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

$ osxcross-conf |grep SDK_VERSION
export OSXCROSS_SDK_VERSION="10.13"

[nephatrine]

I am still getting the issue with clang 13.0.1-6~deb11u1, but moving to LLVM 14 does indeed fix it. I'm not sure why that specific commit breaks my build, but I've got no particular reason to prefer 13 over 14 so that's good enough for me. If it's some peculiarity specific to Debian bullseye's clang13 then I don't want to waste any more of your time on it. Thanks!

[reneleonhardt]

Is the issue resolved? 🙂