Konrad

I would be delighted if I could try to help solve this one. I think I would go with `src/client/components/Sidebar/Topics.js`.

Bumping this issue as ARMs are now supported: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

@KitHat we're having the same issue. Could you double check if you have the resolution for that?

It does not. I pulled the branch and run it on a flake. How about we do something like this: ``` 124 │ diff --git a/jemalloc-sys/build.rs b/jemalloc-sys/build.rs 125 │ index...

The failure is not caused by passing `-Wall` flags, but a bit more indirect. When you pass default compiler flags to `CFLAGS/LDFLAGS`, so `-O0 -Wall`. They end up being in...

Btw. I'm not sure whether `_FORTIFY_SOURCE=3` should be set by default in nix. I was just trying to make this code `agnostic` of this kind of stuff, so should work...

I totally agree, that `-O0` is quite common in the development and it shouldn't create conflicts. I've got no idea why this started showing up recently.

I did another investigation. `__FORTIFY_SOURCE` was also set on the older nix versions with gcc13, however it didn't fail the entire compilation. It didn't detect [`strerror`](https://github.com/jemalloc/jemalloc/blob/257e64b968ec40c285331dfb6e3db8a2b34999d1/src/malloc_io.c#L99) properly, but it didn't...

Given all of that, I think it's fair to say that if someone was using this library via compiler with `__FORTIFY_SOURCE` enabled (hopefully just Nix users (?)), they ended up...

gcc14 with _FORTIFTY_SOURCE=3 on nix ``` checking whether strerror_r returns char with gnu source is compilable... no checking whether compile fail due to strerror_r signature is compilable... no src/malloc_io.c: In...