search

AppImageCrafters / AppRun

AppDir runtime components
MIT License
26 stars 10 forks source link

Add libstdc++ runtime switching support #58

Open azubieta opened 2 years ago

azubieta commented 2 years ago

This has already been done at: https://github.com/darealshinji/AppImageKit-checkrt/

TheBrokenRail commented 2 years ago

On the same note, can you also make it so that it checks glibc version per-architecture? So for instance, if your host system's x86_64 glibc is newer than the bundled glibc, but the host doesn't even have an ARM glibc while the bundle does, it will use the host's glibc for x86_64 programs and the bundled glibc for ARM programs. Thanks!

probonopd commented 2 years ago

Wouldn't an ARM system have all libs as ARM versions?

TheBrokenRail commented 2 years ago

This is for the rare case where an x86_64 AppImage that runs on x86_64 systems contains ARM components which need an ARM glibc (using QEMU probably).

TBH, a better example would be x86_64 and i386. The AppImage could have an older x86_64 glibc, but a newer i386 glibc (or the host could theoretically not have an i386 glibc at all).

As far as I'm aware no big distribution is actually like this right now. This change woudl mostly be for future-proofing and weird edge-case scenarios like mine.

probonopd commented 2 years ago

I fear it might break edge cases more than it'd help.

TheBrokenRail commented 2 years ago

Which edge cases would it break?

Right now it chooses whether to use the bundled or system GLibC based on the host system's GLibC version. If it chooses the host system's GLibC but it doesn't have an architecture installed that the bundled version includes, it just fails.

Right now I'm forced to workaround this using libc6-armhf-cross and manual interpreter patching.

probonopd commented 2 years ago

Which edge cases would it break?

I was thinking of, e.g., running things in, e.g., Box86 and similar solutions.