Re: cross-build aarch64 from macOS not working? Seems to be a result of newer gcc?

[Rob Newberry <robthedude%mac.com@localhost>]

>> Yes!
>> 
>> Thank you so much.  The symptoms are exactly the same, and the patch does indeed appear to fix the build problem — everything builds now.
>> 
>> Really appreciate you pointing me in this direction!
> 
> Nice!
> 
> What version of clang/llvm and macOS is this btw?  The gcc bug report
> mentioned clang 9.0 so I did a few tests and indeed cannot build gcc
> up to 10.4.0 with clang 9.0.  I was able to compile gcc 9.2.0 with
> clang 9.0.1 and I'm right now fairly far into a gcc 11.1.0 build with
> clang 9.0.  But if this happens with a compiler shipped by a major
> vendor it will likely affect more people so we should patch it in our
> tree some way or the other.

That would be awesome, though I’m just glad to not be stuck again :-).

I’m running macOS 12.6, which is the latest at the moment, but 13.x will ship any day now (though I don’t think it’ll run on this particular machine).

I’m using Xcode 14.0.1, which is the latest and I think the same version that 13.x will use.

As you likely know, Apple has their own clang/llvm (https://opensource.apple.com/projects/llvm-clang/) that they maintain, but I think Apple tries to keep in pretty close sync with the main development.

Here’s more from the tools themselves:

	> clang --version
	Apple clang version 14.0.0 (clang-1400.0.29.102)

	> echo "int main(void) { return 0; }" | clang -dM -E - | grep __clang_
	#define __clang__ 1
	#define __clang_literal_encoding__ "UTF-8”
	#define __clang_major__ 14
	#define __clang_minor__ 0
	#define __clang_patchlevel__ 0
	#define __clang_version__ "14.0.0 (clang-1400.0.29.102)”
	#define __clang_wide_literal_encoding__ "UTF-32”

Cheers!

Rob