Comments (14)
Very interesting! The basics seem to be in place - I can run the AppImage even on FreeBSD helloSystem and it doesn't explode 👍
It prints this message:
FreeBSD% runappimage ~/Downloads/NXEngine-Evo-v2.6.5+138a3e2-Linux-x86_64+musl+deps.AppImage
AppRun org.nxengine.nxengine_evo.png
dev proc
etc tmp
home usr
lib var
org.nxengine.nxengine_evo.desktop
terminate called after throwing an instance of 'spdlog::spdlog_ex'
what(): Failed opening file debug.log for writing: Read-only file system
Abort trap
Seems to suggest that the musl part is working just fine, but something wants to write inside the AppImage, which obviously is not going to work by design. Hope this is easy to fix.
When I extract the AppImage and run the AppRun
in the AppDir, I get
I'd call this a resounding success. Speaking of sound, /etc/alsa/conf.d/10-samplerate.conf
does not exist on FreeBSD but I'd say this is an issue of the application rather than your packaing method.
Congrats, this is awesome. Awesome beyond belief! Might be a good way to low-overhead truly compatible (even with FreeBSD!) AppImages. My logic being, if it can run on FreeBSD, it should run on pretty much all Linuxes.
from appimage-builder.
I made a prototype of this from scratch using witchery, a tool made by one of the Alpine devs for making filesystem images that contain all dependencies for an app and nothing else. Witchery is only ~150 lines of POSIX shell, so appimage-builder could either use it or re-implement it from scratch. abuild, the Alpine package building tool, and apk, the Alpine package manager, do most of the heavy lifting.
Here's what my prototype does:
- The app has to be build on Alpine or in a chroot. Installing Alpine in a chroot is very easy (manual instructions, automated script).
make install
the app to a staging area.- Use witcher-buildapk to package the app itself with all its assets. It puts the whole staging directory into an apk file. abuild auto-detects all dependencies by tracing the dynamic library requirements with scanelf.
- Use witcher-compose to build the AppDir. witcher-compose basically shells out to the normal Alpine package manager to install the apk file we just made to the AppDir with all its dependencies. At this point I had to use a flag on witcher-compose to say "Please also install these libraries that my application is going to dlopen at runtime". appimage-builder is better at this because of the strategy it uses of grabbing every file that the app touches at runtime.
- Finally, write a 2 line shell script to use as the AppRun to set the LD_LIBRARY_PATH and run the app.
It's just a prototype, and the process is a bit messy now, but it's exciting to see a /lib/ld-musl-x86_64.so.1
binary running on Ubuntu. 😃 There is still plenty of engineering work needed here to iron out how this will work with appimage-builder, but the solution is within reach.
from appimage-builder.
Now it works on my end. With audio and input 👍 Awesome job!
Let's get our hands dirty with code, It would be great if you could put in a small doc the whole process to create this bundle so we can add it to appimage-builder
.
from appimage-builder.
Now we have a runtime that can be executed in alpine linux (see: https://github.com/AppImageCrafters/appimage-runtime). But the AppRun is now the one that is dynamically linked to glibc because it uses gnu_get_libc_version
to find the version of that lib in the system.
We need to find another way of doing it. ref: AppImageCrafters/AppRun#61
from appimage-builder.
To be more specific, this is about using musl libc applications (such as those that come with Alpine Linux) as the payload inside AppImages. https://github.com/probonopd/go-appimage can do it, if you run with the -s
option (standalone = bundle everything), like in the example at mumble-voip/mumble#3959 (comment).
Another issue is about making the AppImage runtime run on musl libc based distributions like Alpine Linux, too: AppImage/AppImageKit#1015. Any help on that issue is highly appreciated, too.
from appimage-builder.
appimage-builder
relies on the base system package manager to resolve dependencies, so it's also about supporting apk
.
from appimage-builder.
Another issue is about making the AppImage runtime run on musl libc based distributions like Alpine Linux
@probonopd: Why not statically linking the runtime? Or is there anything stopping you from doing it? As I see, doing so would solve that problem.
@azubieta: I'd like to help with this issue. I've used Alpine in the past.
from appimage-builder.
Oh, I just found this: AppImage/AppImageKit#877 (and related issues).
from appimage-builder.
To make an Alpine base AppImage we need a muslc bound or static runtime. Which is not currently available.
@probonopd are there any plans for it?
from appimage-builder.
@xordspar0 do you have a downloadable example of an AppImage created with your prototype? I'd like to try it out. Thanks!
from appimage-builder.
Sure! I uploaded it here: https://github.com/xordspar0/nxengine-evo/releases/tag/alpine-inside
This version isn't any smaller than the Ubuntu-based AppImage, but I think that's because I installed more dependencies than necessary in the "add libraries until all the dlopen
s succeed" step. There's more investigation to do here.
from appimage-builder.
Hello @xordspar0 this looks really interesting!
I tried the AppImage you shared and it still requires /lib/ld-musl-x86_64.so.1
which means that you need use it to launch the application in your AppRun. It would be something like this:
LD_LIBRARY_PATH=$HERE/lib:$HERE/usr/lib LIBGL_DRIVERS_PATH=$HERE/usr/lib/xorg/modules/dri $HERE/lib/ld-musl-x86_64.so.1 $HERE/usr/bin/nxengine-evo
After that fix I got the following error, which is something I was fearing. The bundled graphic libraries are not compatible with my system. This is why AppImages are a bit "permeable" and use some of the system resources. So to make this work we should be able to allow the application load the system graphics libraries.
from appimage-builder.
it still requires /lib/ld-musl-x86_64.so.1
Oh, that's weird. I didn't realize I had ld-musl installed on my system. Thanks for the easy fix.
The bundled graphic libraries are not compatible with my system.
Oops, that it my mistake. You may be right that it's a good idea to make the app use system graphics libraries, but that's actually not the issue you're running into. When this app prints that message, it actually means that it couldn't find the graphics assets. I forgot to compile with position-independent resource paths.
Thanks for taking a look! I fixed these two issues and uploaded another image to https://github.com/xordspar0/nxengine-evo/releases/tag/alpine-inside.
from appimage-builder.
Running postmarketOS, which is built on alpine, on my laptop, leaving comment here to get pinged for development of this issue and can test stuff if needed.
from appimage-builder.
Related Issues (20)
- appimage-builder wants to be run as root because of `pacman -Fy` HOT 22
- deploying package with apt throws an error in version.py HOT 3
- deploying via pacman require root permissions HOT 1
- Standardize on zstd compression HOT 2
- IndexError: list index out of range
- Debug "cannot open shared object file: no such file or directory"
- When AppDir contains a space character, apt package installation fails
- appimage-builder InvalidVersion(f"Invalid version: '{version}'") HOT 7
- How to run gdk-pixbuf-query-loaders --update-cache HOT 2
- Can't select my binary during recipe generation
- E: No packages found
- Generated appimage produces a segmentation fault
- Built images are not respecting XDG spec when it comes to default XDG_DATA_DIRS issue
- FilePackageResolver dpkg-query -S | OSError: [Errno 7] Argument list too long: '/bin/sh'
- strace, dpkg-query, and incorrect library paths
- Appimage creation fails for Retroarch - Arch Linux
- Error running on github workflow HOT 5
- exited with code 127 HOT 2
- Verify release executable file
- Can't execute binaries with sudo inside AppImage - "command not found"
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from appimage-builder.