4 ms·
I played with Appimages a while ago, trying to create one from scratch with a Ruby interactive shell inside. It worked well until I tried it on an older Ubuntu,
by sdwolfz 5y ago
I played with Appimages a while ago, trying to create one from scratch with a Ruby interactive shell inside. It worked well until I tried it on an older Ubuntu, it gave me glibc errors. To make it work I had to find a docker image with an old enough glibc to use as my "compiler", then copy over everything to the Appimage. I also tried compiling an older glibc from scratch inside the Appimage, that solved nothing, as well as needing to install all the binutils that I wanted to embed in the Appimage and make sure the PATH does not contain any host os paths.
It was a nice learning experience, but far from the "Easy to make, runs everywhere" marketing Appimages have.
Does using muls libc and statically linking everything actually work out in practice? I read somewhere (HN comment, don't have reference) that it still might not be enough and your programs still need to the OS libc.
- rubicks 5y agoChanging out glibc for musl can be done if you control the linker invocations on the object files. This would be extremely difficult (but not impossible) for those like myself that use closed-source third-party shared objects linked against glibc.
- jcelerier 5y ago> To make it work I had to find a docker image with an old enough glibc to use as my "compiler", it's not like it is esoteric knowledge though: https://docs.appimage.org/reference/best-practices.html#binaries-compiled-on-old-enough-base-system https://docs.appimage.org/reference/best-practices.html#bina...