Is your feature request related to a problem? Please describe. Until 66eb733c9f6419a495aaa3c46e3ebdacd1e132e5 it was possible to just use the appimage on any system I'm using (which includes RHEL8 and older Debian), as long as QT's dependencies (not that much but at least opengl) were installed via the system package manager.
With QT6 there are more dependencies like libwayland, but the biggest issue is the glibc dependency.
Describe the solution you'd like Either provide an appimage which contains the glibc required (and also package those dependencies for the debuginfo tarball) or (possibly much easier) provide two appimages - one using the old definition and QT5, the other "latest edge" as it is now.
Describe alternatives you've considered Use a working old appimage - but that's quite old already; self-built... that's a lot of dependencies - which is the reason for providing the AppImage in the first place :-)
Additional context AppImage suggests in its forum to use tools like appimage-builder to also include system libraries like glibc in the AppImage (doing so may also make bundling things like libgl/libwayland easier I don't know).
Activity
28we are building on almalinux v9, as centos was cancelled. I'm afraid there's no alternative to us - or rather, if you want to bring back support for rhel8 you'll have to do the work yourself. have a look at scripts/appimage and the Dockerfile therein. Basically, if you can find a suitable replacement with an older system such that ./build_docker.sh && ./build_appimage_in_docker.sh works then I'm happy to accept patches.
but it's a ton of tedious work and I have zero inclination to do that work I'm afraid.
we are building on almalinux v9, as centos was cancelled. I'm afraid there's no alternative to us - or rather, if you want to bring back support for rhel8 you'll have to do the work yourself. have a look at scripts/appimage and the Dockerfile therein. Basically, if you can find a suitable replacement with an older system such that ./build_docker.sh && ./build_appimage_in_docker.sh works then I'm happy to accept patches.
but it's a ton of tedious work and I have zero inclination to do that work I'm afraid.
we are building on almalinux v9, as centos was cancelled. I'm afraid there's no alternative to us - or rather, if you want to bring back support for rhel8 you'll have to do the work yourself. have a look at scripts/appimage and the Dockerfile therein. Basically, if you can find a suitable replacement with an older system such that ./build_docker.sh && ./build_appimage_in_docker.sh works then I'm happy to accept patches.
but it's a ton of tedious work and I have zero inclination to do that work I'm afraid.
we are building on almalinux v9, as centos was cancelled. I'm afraid there's no alternative to us - or rather, if you want to bring back support for rhel8 you'll have to do the work yourself. have a look at scripts/appimage and the Dockerfile therein. Basically, if you can find a suitable replacement with an older system such that ./build_docker.sh && ./build_appimage_in_docker.sh works then I'm happy to accept patches.
but it's a ton of tedious work and I have zero inclination to do that work I'm afraid.
we are building on almalinux v9, as centos was cancelled. I'm afraid there's no alternative to us - or rather, if you want to bring back support for rhel8 you'll have to do the work yourself. have a look at scripts/appimage and the Dockerfile therein. Basically, if you can find a suitable replacement with an older system such that ./build_docker.sh && ./build_appimage_in_docker.sh works then I'm happy to accept patches.
but it's a ton of tedious work and I have zero inclination to do that work I'm afraid.
We can static link everything with musl toolchain. I have successfully done it
We can static link everything with musl toolchain. I have successfully done it
We can static link everything with musl toolchain. I have successfully done it
We can static link everything with musl toolchain. I have successfully done it
You can see my project https://github.com/fifbroman8/hotspot-bin hotspot and perfparser are both static link executables
You can see my project https://github.com/fifbroman8/hotspot-bin hotspot and perfparser are both static link executables
I see. The binaries you've created with muslc-static has indeed no external dependencies and runs even on CentOS7. @milianw That would mean "no appimage needed" or creating it from only those two binaries, no?
I think creating the muslc buildroot would need to have to go to https://github.com/KDAB/hotspot/blob/master/scripts/appimage/Dockerfile and copy it to the container, while specifying the toolset later would have to go to https://github.com/KDAB/hotspot/blob/master/scripts/appimage/build_appimage.sh for the "final" build.
@fifbroman8 Is this something you could inspect?
I see. The binaries you've created with muslc-static has indeed no external dependencies and runs even on CentOS7. @milianw That would mean "no appimage needed" or creating it from only those two binaries, no?
I think creating the muslc buildroot would need to have to go to https://github.com/KDAB/hotspot/blob/master/scripts/appimage/Dockerfile and copy it to the container, while specifying the toolset later would have to go to https://github.com/KDAB/hotspot/blob/master/scripts/appimage/build_appimage.sh for the "final" build.
@fifbroman8 Is this something you could inspect?
I see. The binaries you've created with muslc-static has indeed no external dependencies and runs even on CentOS7. @milianw That would mean "no appimage needed" or creating it from only those two binaries, no?
I think creating the muslc buildroot would need to have to go to https://github.com/KDAB/hotspot/blob/master/scripts/appimage/Dockerfile and copy it to the container, while specifying the toolset later would have to go to https://github.com/KDAB/hotspot/blob/master/scripts/appimage/build_appimage.sh for the "final" build.
@fifbroman8 Is this something you could inspect?
I see. The binaries you've created with muslc-static has indeed no external dependencies and runs even on CentOS7. @milianw That would mean "no appimage needed" or creating it from only those two binaries, no?
I think creating the muslc buildroot would need to have to go to https://github.com/KDAB/hotspot/blob/master/scripts/appimage/Dockerfile and copy it to the container, while specifying the toolset later would have to go to https://github.com/KDAB/hotspot/blob/master/scripts/appimage/build_appimage.sh for the "final" build.
@fifbroman8 Is this something you could inspect?
Just for fun, no idea. I have built x86_64/arm64/powerpc64/loongson64 https://github.com/fifbroman8/hotspot-bin/releases/tag/v2.0.0/
Just for fun, no idea. I have built x86_64/arm64/powerpc64/loongson64 https://github.com/fifbroman8/hotspot-bin/releases/tag/v5.0.0/
Just for fun, no idea. I have built x86_64/arm64/powerpc64/loongson64 https://github.com/fifbroman8/hotspot-bin/releases/tag/v5.0.0/
Just to note how to start it: HOTSPOT_PERFPARSER=$(which hotspot-perfparser) hotspot - or, with #780 just start the static hotspot binary (after having it in PATH)
we are building on almalinux v9, as centos was cancelled. I'm afraid there's no alternative to us - or rather, if you want to bring back support for rhel8 you'll have to do the work yourself. have a look at
scripts/appimageand theDockerfiletherein. Basically, if you can find a suitable replacement with an older system such that./build_docker.sh && ./build_appimage_in_docker.shworks then I'm happy to accept patches.but it's a ton of tedious work and I have zero inclination to do that work I'm afraid.