⭐️NINIKA⭐️

What worked for me was using just `println!("cargo:rustc-link-lib=dylib=fmt");` Maybe these horrors could be alleviated by providing a musl statically-linked version of touchHLE

Other problems: on linux openal depends on `sndio` it seems. Only shared on linux. Hacked by adding `println!("cargo:rustc-link-lib=dylib=sndio");` to `src/audio/openal_soft_wrapper/build.rs`. Maybe a better solution would be to use pkg-config to...

After these hacks I can build touchHLE on arch linux and run Super Monkey Ball =)

> since a friend of mine told me that would be useful on Linux. Yeah, this is kinda expected of local builds, especially for apps with GUI

Just to be less ambiguous, here's a diff: ```diff diff --git a/src/cpu/dynarmic_wrapper/build.rs b/src/cpu/dynarmic_wrapper/build.rs index e008e37..6b9b100 100644 --- a/src/cpu/dynarmic_wrapper/build.rs +++ b/src/cpu/dynarmic_wrapper/build.rs @@ -67,11 +67,12 @@ fn main() { .join("build/externals/fmt") .join(build_type_windows()), );...

I can contribute Flatpak packaging stuff if you want, as I was playing around with them recently.

Hmm, this seems to build fine now in both static and shared configurations! Static (w/o any flags): ```bash $ ldd target/release/touchHLE linux-vdso.so.1 (0x00007ffdea37a000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fcf10c00000) libsndio.so.7 => /usr/lib/libsndio.so.7...

It's a re-implementation of an existing commercial VN game engine, to make it possible run games written for it on new platforms (PC and maybe web). I want it to...

Isn't the contents of `darling::Error::custom` designed for human-readable text that later gets wrapped into `compile_error!` invocation? `manyhow` already does have an of `ToTokensError` for `darling::Error`, so that direction is not...

The error message is whatever the compiler spits out when parsing the `compiler_error!` invocations. Now that I think of it, it might also make sense to make the `Display` impl...