Back

Oh okay that was just my mistake. Thank you goodness I don't have to debug cmake

Now building LLVM myself

Ok I do need to debug CMake. It's giving CMAKE_C_COMPILER_ARCHITECTURE_ID = X86 when I certainly got aarch64 things

This is blocking LLVM build, but for now I'll just let it build with x86 compiler... But does MSVC support cross compiling? Am I building an x86 LLVM for absolutely no reason?

Given it's using Hostx86/x86/cl.exe I feel like it... For cross compiling it should at least use Hostx86/arm64. Oh no

Okay it's not CMake, it's either me or Microsoft. Because Developer Command Prompt by default uses x86 host with x86 target for no good reason. Oh no oh no

On x86-64 system I saw Developer Command Prompt (x64) but I don't see the same for arm64. Huh

With https://stackoverflow.com/a/41728434 I got mine and now everything points to ARM64 tools. This should work. Let's go!

A greatly reasonable person said me that just use x86 tools for less headache. I can't because I'm dumb. And that's absolutely slow for good reasons and I hate it

-- LLVM host triple: aarch64-pc-windows-msvc
-- Native target architecture is AArch64

I didn't read last time and it was x86. Now it's aarch64, everything should work now, right?

Some tags so that future dummies like me can solve their build problems #windows #aarch64 #arm64

BTW why aarch64/ARM64? Why couldn't we agree on choosing either one for everywhere?

So my build is almost done. I heard the binary distributions on #LLVM GitHub are uploaded by contributors, how do I do that?

So it was done, but from mach I got:

0:30.31 DEBUG: | wasm-ld: error: cannot open D:\llvm-project\build\lib\clang\18\lib\wasi\libclang_rt.builtins-wasm32.a: no such file or directory

so I'm building with compiler-rt again.

I'm just building with cmake alone, but maybe I should use https://searchfox.org/mozilla-central/source/build/build-clang/build-clang.py ...

But with SUPPORTED_TARGETS not including windows aarch64 I'm not sure, I'll try with pure cmake build first

And letting mach run is a different story because aarch64 python wants to compile all the wheels locally because pypi doesn't have them

With of course build failures. (That's the good thing with prebuilt wheels, )

cl : Command line warning D9002 : ignoring unknown option '-march=armv8-a'

Boo.

maybe I can re-cmake with the clang I built and then maybe it would work.

Dear me: Don't rewrite on the same build dir, that's dumb

get_host_triple fails if c compiler is clang...

Trying with build-clang.py. It's absolutely written by the awesome people so it should work, right?

That file includes quite some flags btw.

This requires existing clang, so I'm using MS-distributed clang here...

Why not the clang I just built? Because I was lazy and this one also builds into the same directory.

Several trials failed because of Firefox expecting a bit more than just bare clang... I think I should just trigger taskcluster job to build one for me.

So back to the python problem I did not mention above: dependencies fail to install because setuptools only expects `X86.X64` variant of MSVC. https://github.com/pypa/setuptools/issues/4553

I can probably just install x86/64 compiler and work around this, as this is just python issue... or can I? will aarch64 python be able to use x86-64 binary?

Using x86-64 python is mostly okay but that makes the default build target to x86-64 which is annoying

Anyway one by one, let's fix setuptools and people will get less pain in the future

One thing I'm happy with is that there is no "Program Files (x86-64)" on aarch64 Windows. Microsoft learned that having multiple Program Files directories are more pain than anything else.

So some good updates: three things are landing/landed:

Building aarch64 clang: https://bugzilla.mozilla.org/show_bug.cgi?id=1913646
Getting MSVC Hostarm64: https://bugzilla.mozilla.org/show_bug.cgi?id=1913701
Detecting MSVC arm64 installation: https://github.com/pypa/setuptools/pull/4555

@gabrielesvelto As AMD absolutely wanted AMD64 over x64?