AppImage
AppImage for BSD
Why don't you try out yourself. I think the same process can be followed for BSD too. Just try with your native package manager. Come back when you have a problem compiling.
I haven't tried so far; mainly because I don't have a BSD Live ISO that can be live-booted with GRUB2.
@asdedhj have you ever tried to get an AppImage run on BSD? I mean, after all, the only Linux-specific dependency we have is FUSE, which I assume is available on BSD as well. There's a few Linux specific code snippets in our code we could replace, but first, someone should test what needs to be done for proper BSD support.
It would be amazing if AppImages worked with BSD.
While I agree, we won't be working on it unless some BSD user/developer steps up to do it. That person would, of course, have our full support.
Let's not close this, but add the "help wanted" flag instead. We wouldn't reject a PR implementing support for this, of course.
libfuse: available in all the major UNIX (both free and proprietary)
- FreeBSD
- OpenBSD
- NetBSD (as a frontend to puffs)
- Solaris/illumos
- Can't say much for any of the more vendor-specific UNIXes, as I have no hardware to test on
I'm away-from-desk rn, I'll have to take a look at the build documentation soon
I have a tree with FreeBSD support I've just finished.
The only problem is that it currently requires "/proc/curproc/file" ( FreeBSD equivalent of /proc/self/exe ). In theory this is fine, as it works the same as on Linux. However, proc is never mounted by default on FreeBSD. On most linux distros, proc is mounted, and the fuse module is usually loaded by udev at boot. So it would seem that users that will never have root access can use AppImages. On FreeBSD, you would almost certainly have to get root access to at least setup your system for /proc and fuse.
For most FreeBSD users, I'm sure this is acceptable, but I'm not sure how you all feel about it.
Let me know, and ill clean up my changes and make a pull request. Right now my tree has dlopen for fuse removed and all binaries statically linked, so i'll just quickly patch only the stuff needed for FreeBSD in a new tree and make the request if the above issue is tolerable.
@Kolbycrouch, for my freeBSD I feel that your solution could be ok. I hope you provide instruction on installation procedure. I'm challenging the endeavor to install a IOTA Crypto-wallet (Trinity) on my FreeBSD, and it comes in .Appimages (with .yml description files), linux 64 .tar.gz (but I'm not specialized in installing from .tar.gz, only from ports and packages). Thank you very much
Hi @kolbycrouch that's great to hear! Is there any way to try it out without having to wipe a full hard disk?
@probonopd you could just install to a USB disk...
@kolbycrouch that is really the only change needed? Wow, I expected more changes. I'll check how we can check whether we build for a BSD with CMake and will add some preprocessor changes to use the other path then.
Would the Linux binaries "just run" on FreeBSD? Then I'd rather detect the paths during runtime, this isn't black magic.
Can you push your branch somewhere?
We should also check whether there's an alternative to depending on /proc which works on FreeBSD (and maybe even Linux, who knows!).
Wait a second, are we talking about a port of AppImage (i.e., runtime.c is compiled to a native BSD application) or are we talking about using the Linux compatibility layer (i.e., runtime.c and/or the payload is a Linux binary that gets executed through BSD's Linux compatibility layer)?
@kolbycrouch as for the first requirement for Appimages to work in FreeBSD, aka emulating a linux /proc filesysytem, I solved the issue, since FreebSD has a built-in facility for that, called linprocfs filesystem. The command for emulating linux /proc filesystem is: mount -t linprocfs linproc /compat/linux/proc and to load it at boot time open /etc/fstab and add this line: linproc /compat/linux/proc linprocfs rw 0 0
I'm now trying to solve the FUSE issue, without success. I loaded the FUSE kernel module with "kldload fuse" (you can verify with "kldstat") then installed sysutils/fusefs-libs, but when I launch an .Appimage I still see this error: "dlopen(): error loading libfuse.so.2" "Appimages require FUSE to run"
Notice that I see on my system is present /usr/local/lib/libfuse.so.2 (a symbolic link to the actual library) Working on that, and any help would be appreciated, thank you.
Wait a second, are we talking about a port of AppImage (i.e.,
runtime.cis compiled to a native BSD application) or are we talking about using the Linux compatibility layer (i.e.,runtime.cand/or the payload is a Linux binary that gets executed through BSD's Linux compatibility layer)?
I'm talking about porting AppImage to run on FreeBSD. Now that you mention it though, I believe the OP is talking about running a Linux appimage on FreeBSD.
Right now I'm having some problem where the squashfs gets mounted, but I think something goes wrong in creating the temp directory. The appimage will start, run the binary that AppRun points too, but stalls for several minutes trying to unmount the filesystem. Trying to read the temp directory with anything (i.e. /bin/ls or /bin/du) stalls as well. Once I figure it out everything should be good to go.
Quick question though. After glancing over runtime.c some more, it looks like we remove the files that are mounted? Am I wrong about this, or is this really how it works? If so, why not simply unmount the filesystem?
@brunobiondo If you want to run a Linux appimage, you will need ALL the dependencies that AppImage needs placed in the /compat/linux directory. The easiest way to do this is probably extracting a full rootfs of the latest Ubuntu lts and perhaps even chrooting into it to install everything else you need. I'm not 100% sure if that will work, but I've seen guides on the internet about running full distros in a chroot on freebsd.
Keep in mind though. The compat layer is not complete. You may end up running into some issue where a syscall isn't implemented, and the error might be quite cryptic to you.
The best thing to do would be to see if you can build a freebsd binary from source if it's available. I messed around with a few crypto miners/wallets a couple of years ago, and was able to get everything except for the CUDA-dependent stuff working. This way you won't need linux compat or AppImage support.
Quick question though. After glancing over runtime.c some more, it looks like we remove the files that are mounted? Am I wrong about this, or is this really how it works? If so, why not simply unmount the filesystem?
The workflow is:
- create tempdir as mountpoint
- mount AppImage contents to temporary mountpoint
- launch contents; wait for termination
- unmount temporary mountpoint
- clean up temporary mountpoint directory
I'm talking about porting AppImage to run on FreeBSD
Ok, I understand you are trying to port native AppImage support to FreeBSD :) Thanks also for the help from @TheAssassin
The best thing to do would be to see if you can build a freebsd binary from source if it's available. I messed around with a few crypto miners/wallets a couple of years ago, and was able to get everything except for the CUDA-dependent stuff working. This way you won't need linux compat or AppImage support.
Yes, I'm trying to install a wallet for the upcoming groundbreaking IOTA crypto currency. UPDATE 2/2/2019 Trying to build from sources, as per instructions at https://github.com/iotaledger/trinity-wallet (or alternatively https://github.com/iotaledger/wallet), but it's a bit complicated, the application is based on ReactJs and built with React-Native (mobile) and Electron (desktop): different javascript package managers are required (yarn, npm) for installing the stuff, and I get stuck at a point in the installation, so I looked for pre-compiled packages at https://github.com/iotaledger/trinity-wallet/releases
@brunobiondo If you want to run a Linux appimage, you will need ALL the dependencies that AppImage needs placed in the /compat/linux directory. The easiest way to do this is probably extracting a full rootfs of the latest Ubuntu lts and perhaps even chrooting into it to install everything else you need. I'm not 100% sure if that will work, but I've seen guides on the internet about running full distros in a chroot on freebsd.
I follow your advice, I will not try to run a Linux AppImage, but I have a curiosity just en-passant, and would like your opinion: but in general installing a rootfs in a docker container could it be a viable solution for testing applications written for other OSes?
If you want to run a Linux appimage, you will need ALL the dependencies that AppImage needs placed in the /compat/linux directory.
Out of curiosity, please try the Inkscape 1.0 pre-alpha AppImage from inkscape.org. Unlike most other AppImages, this one bundles everything, so there should be no external dependencies. I am wondering how it would fare with the BSD Linux compatibility layer. As a temporary workaround as long as FUSE is not working, you can extract and run it with --appimage-extract-and-run...
Hi @probonopd, as per your suggestions, and after having set up linux compatibility as per instructions here https://www.freebsd.org/doc/handbook/linuxemu-lbc-install.html, this is the output from running the Inskscape pre-alpha Appimage:
/root > ./Inkscape-9dee831-x86_64.AppImage --appimage-extract-and-run [....] /tmp/appimage_extracted_42c161d9501409a8e1d6892625d64f26/usr/share/themes/Adwaita-dark/index.theme /tmp/appimage_extracted_42c161d9501409a8e1d6892625d64f26/usr/share/thumbnailers /tmp/appimage_extracted_42c161d9501409a8e1d6892625d64f26/usr/share/thumbnailers/librsvg.thumbnailer [...] ELF Binary type "0" not known /compat/linux/tmp/appimage_extracted_42c161d9501409a8e1d6892625d64f26/AppRun: line 67: /compat/linux/tmp/appimage_extracted_42c161d9501409a8e1d6892625d64f26/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2: cannot execute binary file /compat/linux/tmp/appimage_extracted_42c161d9501409a8e1d6892625d64f26/AppRun: line 67: /compat/linux/tmp/appimage_extracted_42c161d9501409a8e1d6892625d64f26/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2: Success /root >
Also notice that using 'brandelf -t linux ./Inkscape-9dee831-x86_64.AppImage' PRODUCED NO OUTPUT.
OK, so it seems like the extraction does work but running lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 does not. Thanks for having tested it. (This AppImage is an exception; other AppImages don't usually run lib/x86_64-linux-gnu/ld-linux-x86-64.so.2.)
Hi @probonopd, I've read the section about FUSE here https://github.com/AppImage/AppImageKit/wiki/FUSE, where you cite AppRun, then I noticed that AppRun is a bash shell script, and wanted to point out that the so-called she-bang (1st line) for where to search the shell interpreter, in AppRun is '#!/usr/bin/bash'. This can work for many unix flavors OSes, but in FreeBSD, by default, the interpreters are put in /usr/local/bin, and there are some (posix?) specifications that come in aid for more portability in general: specify the she-bang as '#!/usr/bin/env bash', ~~this should rely on the $SHELL environment variable~~ this calls the env utility that searches in the directories specified in the $PATH environment variable (unless otherwise specified), then invokes the specified argument (interpreter). (For most of my few local shell scripts, I'm lazy in still using '#!/usr/local/bin/fish', and I know they could not be portable across different platforms). I hope that this can be helpful to AppImage developers.
Thanks @brunobiondo. The different shells are not always 100% compatible, so I explicitly set it to bash to ensure that the Bourne Again Shell is used.
Every AppImage may contain something else as the AppRun entry point. Some AppImages use a compiled (C) executable as the AppRun, others (e.g., those generated by linuxdeployqt) use just a symlink to the main executable.
So to become more "Linux compatible", BSD users might install a symlink to the Bourne Again Shell in /usr/bin/bash?
Hi @probonopd, given that the AppRun I poke around is a bash shell script extracted from the AppImage available (among other packaged formats) on the IOTA Trinity wallet project at https://github.com/iotaledger/trinity-wallet/releases. I know that unfortunately :( there may exist even big behavioral and syntax differences among various kinds of unix shell interpreters that have historically occurred over the years (from Bourne to Korn to C Shell to Bourne Again to Zsh and others: I personally use the youngest, much more linear and syntactically clear, yet powerful as well and less error-prone Fish shell, but that's another story). That's why it is a normal habit to specify which interpreter to choose in the she-bang, like, in the case of the Trinity's AppRun is '#!/usr/bin/bash'. And I said that you can also specify bash by putting this shebang: '#!/usr/bin/env bash', that is more portable across different unixes and unix-likes. That said, as a FreeBSD user, if I were to make bash script with 'first-style shebang' working, I would opt for your proposal, that is making a symlink /usr/bin/bash that points to the real Bourne Again shell.
Hi! I think too that simplest solution is writing this shebang: #!/usr/bin/env bash
It's a good habit to write in scripts to run in GNU/Linux as well...
Honestly, I think the shebang is the tiniest of all issues in porting AppImage to BSD... now prove me wrong ;-)
Hi probonopd :-) For me it's a pleasure talking with you.
I have downloaded Waterfox browser in appimage format. Launching it, it looks for "libfuse.so.2", but it doesn't find it for a mere path problem: libs, in FreeBSD, are in /usr/local/lib. Anyway, I linked /usr/local/lib to a "/usr/lib64" and I downloaded there a libfuse.so.2. It worked, as S.O. loaded the library, but (and this is the real problem) afterwards it complained:
error while loading shared libraries: /usr/lib64/libfuse.so.2: ELF file OS ABI invalid
You have to use proper ABI's libs for BSD. Hence, my tip:
[ ${#OSTYPE} -gt 0 ] && os=${OSTYPE} || os="$(uname -s )"
[ $(echo -n "${os}" | grep -i "bsd" | wc -c ) -gt 0 ] && mascotte="Beastie" || mascotte="Tux"
So, if mascotte is Beastie, you should give a customized lib for FreeBSD.
Maybe it makes sense... I'm trying to help... What do you think about?
The following has been reported to work on FreeBSD 11.2-RELEASE-p7:
wget https://github.com/AppImage/AppImageKit/releases/download/12/appimagetool-x86_64.AppImage
chmod +x ./appimagetool-x86_64.AppImage
./appimagetool-x86_64.AppImage --help --appimage-extract-and-run
If we want to make it work without --appimage-extract-and-run, then we need a way to make libfuse work on *BSD. It seems that there have been some BSD specific patches to libfuse lately: https://github.com/libfuse/libfuse/issues/173
Can someone who has BSD please check whether https://github.com/kost/static-appimage/releases works there? Construct a zip that contains an executable .AppRun bash script, and append that zip to one of the runtimes from https://github.com/kost/static-appimage/releases. I'd be interested to see whether it works on BSD. Those runtimes are statically linked, which means they need no libfuse...
Nope!
vittorio@ThinkpadFreeBSDVITT:~/Programmi$ chmod +x ./appimagetool-x86_64.AppImage vittorio@ThinkpadFreeBSDVITT:~/Programmi$ ./appimagetool-x86_64.AppImage --help --appimage-extract-and-run ELF binary type "0" not known. bash: ./appimagetool-x86_64.AppImage: cannot execute binary file: Exec format error
It seems to have still problems... :(
Vittorio
Il giorno mar 16 lug 2019 alle ore 17:19 probonopd [email protected] ha scritto:
The following has been reported to work on FreeBSD 11.2-RELEASE-p7:
wget https://github.com/AppImage/AppImageKit/releases/download/12/appimagetool-x86_64.AppImage chmod +x ./appimagetool-x86_64.AppImage ./appimagetool-x86_64.AppImage --help --appimage-extract-and-run
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AppImage/AppImageKit/issues/98?email_source=notifications&email_token=ABDFPQZYPCWWS7GCNTI5H5TP7XRJXA5CNFSM4B4S7YIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2BGORI#issuecomment-511862597, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDFPQZRR7GZTGB3A76ZC2DP7XRJXANCNFSM4B4S7YIA .
FreeBSD has a working FUSE. With a few short changes to the build system, you can get AppImageKit to build against FreeBSD without issue. You can also create an appimage.
The problem is when you start the appimage. the process hangs for about ~1 minute around the time that it creates the tmp directory/mounts the appimage. Any reads into /tmp even freeze up for the whole time.
There were no unique compiler warnings compared to a linux build, and I didn't have enough time to figure out why that was happening. It could be the kernel, the libfuse port or the porting I did.
I'm currently building a statically linked AppImage runtime and libfuse for full portability. Dynamically linking the runtime and using dlopen() for libfuse make the AppImage a lot less portable. Static linking works great using musl and freebsd's libc, it's probably safe enough for glibc too.
The problem is when you start the appimage. the process hangs for about ~1 minute around the time that it creates the tmp directory/mounts the appimage. Any reads into /tmp even freeze up for the whole time.
Hi @kolbycrouch does this also happen with the ones from https://github.com/kost/static-appimage/releases? That is an entirely different code base, written in Go.