Martin Storsjö

> It would be nice to see this merged, anything still blocking it? I had expected some more followup after the last post above. The main blocking issue was that...

> Setting `CMAKE_SYSROOT` is relevant since CMake itself and Tools parsing the command-line need to know the full paths as they don't get the builtin information from the compiler(-driver). >...

We can’t really do much based on such error messages - you’ll need to provide the minimal input for reproducing the failure.

ARM64X (or ARM64EC) aren’t quite supported yet. The necessary support in LLVM isn’t available in the latest releases (19.x), but it should be mostly supported in the latest git versions...

This change broke a couple of tests in the libyuv testsuite (https://chromium.googlesource.com/libyuv/libyuv). I’ve reproduced the errors for mingw i686, x86_64 and armv7, but no errors on mingw aarch64. Also reproducible...

> Hi, thanks for letting me know. Feel free to revert the patch for now, will investigate it next week. Thanks, I pushed a revert in https://github.com/llvm/llvm-project/commit/bd9486b4ec7dc24f73f32474fa38b522a7cce085.

FWIW, this patch breaks compilation for aarch64 for essentially every configuration concievable, as is. With Clang: ``` codec/common/arm64/mc_aarch64_neon.S:35:1: error: unknown directive .rodata ^ codec/common/arm64/mc_aarch64_neon.S:38:1: error: unknown directive .previous ^ ```...

> > FWIW, this patch breaks compilation for aarch64 for essentially every configuration concievable, as is. > > With Clang: > > ``` > > codec/common/arm64/mc_aarch64_neon.S:35:1: error: unknown directive >...

Oh, and I forgot - to get the address of the data in a different section, you probably also need to replicate something like the `movrel` macros in ffmpeg/dav1d, because...

I'm not entirely sure all what's happening here, but I have a few observations at least. When we invoke `-w64-mingw32-clang`, the wrapper script/executable invokes the `clang` binary with a couple...