STATUS_ILLEGAL_INSTRUCTION (0xC000001D) inside statically-linked ggml during Session::run on Windows x64 CPU

[kanakkholwal]

transcribe-cpp 0.1.2: STATUS_ILLEGAL_INSTRUCTION (0xC000001D) inside statically-linked ggml during Session::run on Windows x64 CPU

Repro: v0.4.0 NSIS installer (recast_0.4.0_x64-setup.exe), 84s h264 recording, any model after fresh download.

Faulting module: recast.exe (offset 0x276430b). No Windows error dialog, just process termination reported via WER. Statically-linked ggml CPU dispatch seems to compile in an instruction the runtime CPU can't execute — this matches the __cpuid runtime detection gap if the staticlib was built with GGML_NATIVE=ON (or pre-Skylake AVX-512) and the user's CPU isn't matched.

Apparently here: https://github.com/kanakkholwal/recast/releases

[cjpais]

Did you compile for the same architecture? If you are using GGML_NATIVE it will compile with whatever extensions are supported by the system which compiles it. This means that other systems may not be able to run and will hit this

Basically what machine did you compile on and what did you run on?

If you are looking to widely distribute an application with the best performance anywhere, dynamic linking is preferred. I learned this the hard way with Handy and can tell you all about it if you wish

[kanakkholwal]

So, my local device is AMD Ryzen 7 7435HS with nvidia rtx 3050.
I compiled the tauri app (recast) locally. It works, does the transcription and all. But if I use that same code compiled from my Github Action runners (release-desktop.yml), It gives this silent crash while transcribing.

Although It is fixed in the latest one but was failing with this release-desktop.yml

[cjpais]

If you want wide compatibility you need to turn off GGML_NATIVE

The crash you're experiencing is effectively expected. You compiled with extra CPU acceleration extensions your processor does not support. So when it tries to run it crashes.

You can directly tune what extensions you want to use if you statically compile. If there's an issue in doing that let me know

This issue is more or less expected as far as I can tell. Right now I'm away and I'll take a closer look later. There's no way around it other than to either

1. Statically compile with only the extensions you want
2. Dynamically link (the default of the library) for broadest compatibility

If you need more detail on this let me know. Otherwise you can ask an LLM and it should be able to fill in the gaps.