Mikeserv Support Forum

Posted: **Wed Feb 25, 2026 1:10 am**

Released last night, LLVM 22.1 stable. It's not considered stable until .1 (gcc does that now too)

So, I figured I'd get started on it. It compiled uneventfully, I just plugged it into my custom PKGBUILDs (options are all still valid etc.)

After that, the first thing to test is... can rust build with/against it.

No! It failed. Firstly I missed link-shared = false on my last Rust build so the shared LLVM libraries were broken sonames. Restart with a downloaded cargo and rustc to build the bootstrap. Then it failed soon after bootstrap with a missing header llvm/Passes/PassPlugin.h

I was all WTF, did they remove that header and implement it some other way? No, they just moved it into Plugins. It seems silly, as it's the only file in there. The other, related includes (being included by path) are still in Passes.

So I grepped for it in the rust source, and found it all over the place in llvm-project, but my build isn't going there as I'm using my own. It was only ONE place I needed to change it:

src/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp

The #include line Changed from "llvm/Passes/PassPlugin.h" to "llvm/Plugins/Passplugin.h"

(I didn't make a patch as I was just testing, and it's easier to just change a few characters in a file anyway)

Surely it couldn't be that easy, and this is just the first speed bump. No, that was all that was wrong. Rust 1.93.1 otherwise builds and works fine (both 64 and 32 bit targets) with LLVM 22 (and I did build it in statically this time). I used my rust build to bootstrap another.

My rust compiler and cargo work. Now the real test... can this LLVM/Clang 22 and Rust compile Firefox. I already know I can't do the WASI thing yet, as the wasi-sdk project isn't updated for LLVM 22 (that just won't work until it is) but if I can compile Firefox without that for now, then the LLVM upgrade will be viable.

Posted: **Wed Feb 25, 2026 2:47 am**

Success... Firefox 148.0 built and profiled correctly with my LLVM 22 toolchains, with

"ac_add_options --without-wasm-sandboxed-libraries"

I'm using it now.

Hopefully wasi-sdk rebases on LLVM 22 soon, I won't be able to plug that into LLVM 22 for a firefox build until it is. I don't know how much that matters, it's only a few bundled libraries built that way (it must not have gained any more traction since) and there would have to be some exploit in those libraries for this to prevent. I think it's still only expat, libwoff2 (more font bollocks), ogg/vorbis and graphite (font engine).

A good upgrade, then. Just the WASI sacrificed for now. I don't have to worry about Mesa liking it, because I don't use LLVM in my build (aco for AMD cards)

Posted: **Thu Mar 05, 2026 10:52 pm**

Well... I built a wasi-sdk rebased on LLVM 22.1 today, and all went well until I tried to build Firefox using it. Of course, the firefox code base is unhappy with this, because they've inconsistently used a target that's now become deprecated. On the bright side, it's no longer necessary to hack out BULK_MEMORY_OPS for Firefox's wasm2c

Code: Select all

 0:03.53 checking for clock() in wasi sysroot... no
 0:03.54 checking for emulated clock() in wasi sysroot...
 0:03.54 DEBUG: Creating `/tmp/conftest0z744q9c.c` with content:
 0:03.54 DEBUG: | #include <time.h>
 0:03.54 DEBUG: | int
 0:03.54 DEBUG: | main(void)
 0:03.54 DEBUG: | {
 0:03.54 DEBUG: | clock();
 0:03.54 DEBUG: |   ;
 0:03.54 DEBUG: |   return 0;
 0:03.54 DEBUG: | }
 0:03.54 DEBUG: Executing: `/usr/bin/clang --target=wasm32-wasi /tmp/conftest0z744q9c.c -Werror -D_WASI_EMULATED_PROCESS_CLOCKS -lwasi-emulated-process-clocks --sysroot=/storage2/shit/build/wasi-sysroot`
 0:03.54 DEBUG: The command returned non-zero exit status 1.
 0:03.54 DEBUG: Its error output was:
 0:03.54 DEBUG: | clang: error: argument '--target=wasm32-wasi' is deprecated, use --target=wasm32-wasip1 instead [-Werror,-Wdeprecated]
 0:03.54 ERROR: Can't find clock() in wasi sysroot.
*** Fix above errors and then restart with "./mach build"

It's not just in that conftest, but all over the place in both the C++ and Rust code. Some of it is using target wasm32-wasip1 but much of it is using wasm32-wasi.

I've tried passing -Wno-error but it won't take it for that conftest. So I took the -Werror out of the conf test (firefox-148.0/toolkit/moz.configure

) and so far it's compiling (It should just be warnings when it hits that in the code unless there are more -Werror directives in any other build commands that override my -Wno-error that I've set globally in C/CXXFLAGS)

P.S. On further testing, all that is necessary is to take -Werror out of that WASI conftest (the clock function was just what they picked to test the WASI compiler) for current LLVM 22.1 based wasi-sdk. It's not necessary to set -Wno-error or -Wno-deprecated globally (though I can do without that shit anyway). So I made a patch because it will probably be some time before Mozilla switches to LLVM 22

Code: Select all

--- firefox-148.0_orig/toolkit/moz.configure	2026-02-16 13:37:51.000000000 -0500
+++ firefox-148.0/toolkit/moz.configure	2026-03-05 18:34:03.182344222 -0500
@@ -3021,7 +3021,7 @@
         body="clock();",
         check_msg="for clock() in wasi sysroot",
         flags=depends(wasi_sysroot_flags)(
-            lambda sysroot_flags: ["-Werror"] + sysroot_flags
+            lambda sysroot_flags: sysroot_flags
         ),
     )
 
@@ -3031,7 +3031,6 @@
         check_msg="for emulated clock() in wasi sysroot",
         flags=depends(wasi_sysroot_flags)(
             lambda sysroot_flags: [
-                "-Werror",
                 "-D_WASI_EMULATED_PROCESS_CLOCKS",
                 "-lwasi-emulated-process-clocks",
             ]

I've decided that I don't need to see deprecated warnings. That's up to projects to fix their code, I don't care unless it causes a hard error that I need to fix. Much cleaner build output without deprecated warnings. I'm setting "-Wno-deprecated" for C and C++ and "-A deprecated" for rustc for all builds from now on.

Mikeserv Support Forum

LLVM 22.1

LLVM 22.1

Re: LLVM 22.1

Re: LLVM 22.1