box64 icon indicating copy to clipboard operation
box64 copied to clipboard

musl support

Open xorrvin opened this issue 1 year ago • 7 comments

Hi,

Thanks for this awesome project! I'd like to resurrect previous failed attempts of bringing musl support to box64. So far I've found standard type mismatches (easily fixable), but also there's a fair amount of #define _GNU_SOURCE across the code. What's the main purpose of it? From what it looks like, it can be made a global define via CMake if glibc (default) is used, and not applied for musl.

As for the missing glibc functions, there's this amazing project by Adélie Linux team: https://git.adelielinux.org/adelie/gcompat , but I don't know what exactly do you need from glibc which's missing in musl.

xorrvin avatar Nov 09 '24 13:11 xorrvin

musl support would be nice to have especially with some sort of integration into flatpak. It would be nice to be able to build box64 on a musl libc system with flatpak already installed, somehow set up the two together, and then be able to install x64 flatpaks with an acceptable speed. Sadly, qemu's x64 on arm64 emulation doesn't seem to reach particularly usable speeds.

ell1e avatar Jun 22 '25 13:06 ell1e

what is the link between musl and flatpak?

(side not: I am not currently working on any musl compatibility, as none of my system actualy use musl)

ptitSeb avatar Jun 22 '25 13:06 ptitSeb

As far as I know, flatpak is the common workaround to get glibc programs to run on musl libc systems. box64 seems to be the main viable option to get x64 glibc programs running on arm64 glibc systems. Combining both would enable running x64 glibc Linux programs, the most common kind, on arm64 musl libc systems.

ell1e avatar Jun 22 '25 13:06 ell1e

(I wonder if it would alternatively be possible to run box64 somehow inside the flatpak container. But I wouldn't know how to even start doing that as a user, since somehow I guess I would need to convince flatpak to download an x64 flatpak on arm64 which it likely won't want to do, and then to launch it but somehow with box64 inside.)

ell1e avatar Jun 22 '25 13:06 ell1e

Box64 is actually compatible with AppImages. They just run fine.

As far as flatpak goes, my understanding is that it's more low level than AppImages, and so might not use box64 even if present, and I'm not sure support can be added in box64, or if it needs to be added in flatpak runtime itself, to register "box64" as an x86_64 runner. I have no specific knowledge of flatpak tho, so I'm just speculating.

ptitSeb avatar Jun 22 '25 14:06 ptitSeb

glibc AppImages often won't run on musl libc I think. At least that has been my experience that flatpak is more reliable for that purpose.

ell1e avatar Jun 22 '25 15:06 ell1e

You need to realise that what was asked in the ticket would be to be able to build box64 for musl system to run glibc x64 binary. So regular x64 AppImage would just work...

Also, you need to realise that box64 is quite different from qemu-user: libc is never emulated with box64. So even if it's embeded in the flakpak you wan to run, box64 will not use it and will always use the system one (the aarch64 one). So many of the advantage of embedding libs in flatpak will not work with box64.

ptitSeb avatar Jun 22 '25 17:06 ptitSeb

My apologies, but in any case it would be nice to have the "simple" variant for regular musl x64 binaries too. This could for example be useful for wine, for which there already is a musl build. A flatpak integration that I mentioned would also be nice and might avoid the use of gcompat, but I can file a separate issue for that if wanted, since you're completely right it's kind of a different beast. (If it is possible at all...)

ell1e avatar Jul 11 '25 14:07 ell1e

Well, box64 can build for bionic, so I'm pretty sure it should be fairly easy to build for musl too. I cannot do it as I have no machine running musl for now, but it should be fairly trivial.

ptitSeb avatar Jul 11 '25 17:07 ptitSeb