[ISSUE] Tracking: packages broken on larger pagesize kernels (like rpi5-kernel)

[ISSUE] Tracking: packages broken on larger pagesize kernels (like rpi5-kernel)

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

New issue by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/48260

Description:
Some programs have issues when running on kernels with larger pagesizes.

### jemalloc

One common case is programs (especially rust programs) that use jemalloc. this was fixed in #48194 for the jemalloc package itself and all rust packages built in the future. This often manifests itself like this:
```
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
memory allocation of 5 bytes failed
```

### Probably bad

*as yet untested, based on https://github.com/AsahiLinux/docs/wiki/Broken-Software#broken-packages*

- [ ] qt5-webengine
- [ ] qt6-webengine (qt6-pdf?)
- [ ] zig

Re: Tracking: packages broken on larger pagesize kernels (like rpi5-kernel)

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/48260#issuecomment-1896777508

Comment:
zig was definitely broken last year on 16k, the relevant pr's are in progress https://github.com/ziglang/zig/pull/17382

Re: Tracking: packages broken on larger pagesize kernels (like rpi5-kernel)

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/48260#issuecomment-2108707715

Comment:
For zig, we may consider this patch to mem.zig:
```
pub const page_size = switch (builtin.cpu.arch) {
    .wasm32, .wasm64 => 64 * 1024,
    .aarch64 => switch (builtin.os.tag) {
+        .macos, .ios, .watchos, .tvos, .linux => 16 * 1024,
-        .macos, .ios, .watchos, .tvos, => 16 * 1024,
        else => 4 * 1024,
    },
    .sparc64 => 8 * 1024,
    else => 4 * 1024,
};
```
I don't know how many aarch64 machines this would break, but at least it could be usable on rpi5 and apple.

Re: Tracking: packages broken on larger pagesize kernels (like rpi5-kernel)

[Calandracas606]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

New comment by Calandracas606 on void-packages repository

https://github.com/void-linux/void-packages/issues/48260#issuecomment-2187060905

Comment:
AFAIK F2FS still won't work, since it requires userspace support from f2fs-tools, which hasn't had a release yet.

Re: Tracking: packages broken on larger pagesize kernels (like rpi5-kernel)

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/48260#issuecomment-2308785895

Comment:
Surprisingly, river from void's repo works fine on apple silicon (16k kernel), even though zig is broken. How is this possible??

Re: Tracking: packages broken on larger pagesize kernels (like rpi5-kernel)

[Calandracas606]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

New comment by Calandracas606 on void-packages repository

https://github.com/void-linux/void-packages/issues/48260#issuecomment-2308913221

Comment:
> Surprisingly, river from void's repo works fine on apple silicon (16k kernel), even though zig is broken. How is this possible??

this makes sense, and works for the same reason that any cross compiled binaries work.

the zig ***compiler*** may be broken when using a 16k build machine, but binaries built by the compiler may work just fine.

this is exactly the same as why cross compilers work. the aarch64 gcc cross compiler runs on a x86_64 build machine, and outputs binaries which run on an aarch64 machine

Re: Tracking: packages broken on larger pagesize kernels (like rpi5-kernel)

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/48260#issuecomment-2643557420

Comment:
zig pr implementing runtime page size detect has been merged into master :)