AppImage for BSD

[Achrine]

No description provided.

[kskarthik]

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.

[probonopd]

I haven't tried so far; mainly because I don't have a BSD Live ISO that can be live-booted with GRUB2.

[TheAssassin]

@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.

[probonopd]

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.

[TheAssassin]

Let's not close this, but add the "help wanted" flag instead. We wouldn't reject a PR implementing support for this, of course.

[despair86]

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

[kolbycrouch]

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.

[brunobiondo]

@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

[probonopd]

Hi @kolbycrouch that's great to hear! Is there any way to try it out without having to wipe a full hard disk?

[TheAssassin]

@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!).

[probonopd]

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)?

[TheAssassin]

My guess was the former, but I wasn't sure hence the question.

[brunobiondo]

@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.

[kolbycrouch]

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)?

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.

[TheAssassin]

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:

1. create tempdir as mountpoint
2. mount AppImage contents to temporary mountpoint
3. launch contents; wait for termination
4. unmount temporary mountpoint
5. clean up temporary mountpoint directory

[brunobiondo]

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?

[probonopd]

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...

[brunobiondo]

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.

[probonopd]

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.)

[brunobiondo]

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.

[probonopd]

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?

[brunobiondo]

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.

[probonopd]

I wonder why FUSE doesn't work for you. I've just checked again, this time with Focal userspace, and it seems to work fine.

That's great to hear. Just to verify: You can download an AppImage and run it on FreeBSD with Focal userspace? This would be an awesome achievement!

I wonder why FUSE doesn't work for you.

For one, helloSystem is still FreeBSD 12.2 based, and there I get fuse: mount failed: File name too long when trying to use Linux FUSE (even with a Focal userspace).
(We do make 13.0 based experimental ISOs but I don't have such a system installed to HD yet to experiment with.)

Note to self:

• Installed Chrome from linux-browser-installer, this sets up a Focal userspace
• Installed Linux FUSE into the Focal userspace with sudo chroot /compat/ubuntu /usr/bin/apt-get install fuse (it does not work without chroot)

[trasz]

What I've meant with Focal was testing it by hand using squashfuse(1) in Focal chroot. However, I think I've figured out what's wrong, appimages end up calling the kernel mount(2) function in a somewhat weird way. There's a patch at https://reviews.freebsd.org/D30606 which should make it work. I was able to successfully run scribus-1.5.6.1-linux-x86_64.AppImage, as root, from within Focal chroot. I don't have any experience with Scribus, but it, well, looks okay :-)

Now, regarding the crashes - can you tell me some more about your system? Does your CPU support SMAP, by any chance? The cpuid-etallen port/package should tell.

[probonopd]

Now, regarding the crashes

You are spot on.

Crashes (= instant reboot) on

• brand = "Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz" which has SMAP: supervisor mode access prevention = true

Does not crash (= works) on

• brand = "Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz" which has SMAP: supervisor mode access prevention = false

To reproduce:

• Download https://github.com/helloSystem/ISO/releases/tag/experimental-13.0 (I used hello-0.5.0_0E211-FreeBSD-13.0-amd64.iso which has FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr 9 04:24:09 UTC 2021 [email protected]:/usr/obj/usr/src/amd64.amd64/sys/GENERIC)
• Fix a small bug by editing sudo nano /usr/local/bin/runappimage and changing if [ ! -f "/bin/bash" ] ; then to if [ ! -L "/bin/bash" ] ; then (this will be fixed in newer builds of the ISO)
• Run runappimage /path/to/scribus-1.5.6.1-linux-x86_64.AppImage

[trasz]

I don't have a SMAP-enabled system to test, unfortunately (that would have a display attached), but I'm pretty sure you're hitting the bug fixed in freebsd/freebsd-src@fb580451456 and freebsd/freebsd-src@60cb98a1bd2. The Scribus AppImage worked for me on non-SMAP machine.

[probonopd]

https://github.com/realthunder/FreeCAD_assembly3/releases FreeCAD-asm3-Daily-Conda-Py3-Qt5-20210531-glibc2.12-x86_64.AppImage fails to run using runappimage on FreeBSD 12.2 with /compat/ubuntu/ made by linux-browser-installer with

While initializing FreeCAD the following exception occurred: 'Getting HOME path from system failed!'

Here is the FreeCAD code in question:

https://github.com/FreeCAD/FreeCAD/blob/4de2ad46b2b9c78ac2721a0dbea7c19306261095/src/App/Application.cpp#L2773-L2777

#if defined(FC_OS_LINUX) || defined(FC_OS_CYGWIN) || defined(FC_OS_BSD)
    // Default paths for the user specific stuff
    struct passwd *pwd = getpwuid(getuid());
    if (pwd == NULL)
        throw Base::RuntimeError("Getting HOME path from system failed!");

I get the same error if I extract the AppImage with

./FreeCAD-asm3-Daily-Conda-Py3-Qt5-20210531-glibc2.12-x86_64.AppImage --appimage-extract

and then run ./squashfs-root/AppRun.

@trasz do you have an idea why this fails?

[probonopd]

@trasz Is there a way to expose D-Bus that is running on the FreeBSD side to the Linuxulator?

Example use case:

https://binary-factory.kde.org/view/AppImage/job/Ruqola_Nightly_appimage/lastSuccessfulBuild/artifact/ruqola-master-1-145-linux-64-gcc.AppImage

says

FreeBSD% runappimage Downloads/ruqola-master-1-145-linux-64-gcc.AppImage 
AppRun                  AppRun.wrapped          org.kde.ruqola.desktop  usr
apprun-hooks            etc                     ruqola.png
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-'
Could not create AF_NETLINK socket (Address family not supported by protocol)
(...)
"Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)"

[trasz]

I have a theory why DBus doesn't work and how to fix it (basically make the FreeBSD port use LOCAL_CREDS_PERSISTENT), but it's at guesswork stage at the moment.

[probonopd]

Having D-Bus would possibly allow the https://github.com/LANDrop/LANDrop/releases/ AppImage to run.

[ncorder]

@probonopd Would it be possible to add a page to https://github.com/AppImage/docs.appimage.org about BSD support and tracking its usage as well?

[probonopd]

Once it is working and supported.

[probonopd]

Hello @trasz did you have a chance to look into D-Bus?

Also, do you know whether there is a chance for D30606 to land in 13.0 or 13.1 anytime soon?

Thanks again for your support.

[ykla]

What's about it now?

[probonopd]

FreeBSD 13.1 should possibly start to run AppImages:
freebsd/freebsd-src@6bddc31

[glowiak]

Woah
nice work

[vaisarger]

Hi! Good work! ;) "26 April 2022": I look forward to upgrading! Cheers Il giorno mer 23 feb 2022 alle ore 20:15 probonopd ***@***.***> ha scritto:

…

FreeBSD 13.1 should possibly start to run AppImages: ***@***.*** <freebsd/freebsd-src@6bddc31> — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDFPQ46WMA2FFKJCY5XIXTU4UW4XANCNFSM4B4S7YIA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ykla]

It seems not work. I also try both FreeBSD-13.0-STABLE-amd64-20220217-be8e341777c-249491-disc1.iso and FreeBSD-14.0-CURRENT-amd64-20220224-45c23c2608e-253384-disc1.iso.

root@ykla:~ # kldload fusefs
root@ykla:~ # ./Wine-x86_64-opensuse.latest.AppImage 
dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information
root@ykla:~ # uname -r
13.0-STABLE
root@ykla:~ # uname 
FreeBSD
root@ykla:~ # uname -a
FreeBSD ykla 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n249491-be8e341777c: Thu Feb 17 02:37:38 UTC 2022     [email protected]:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
root@ykla:~ # 

[probonopd]

Do you have libfuse.so.2 installed in your Linux compatibility environment?

[ykla]

Do you have libfuse.so.2 installed in your Linux compatibility environment?

OK. I install libfuse.so.2, but also not work.

root@ykla:~ # wget http://mirror.centos.org/centos/7/os/x86_64/Packages/fuse-libs-2.9.2-11.el7.x86_64.rpm
root@ykla:/compat/linux # rpm2cpio < /root/fuse-libs-2.9.2-11.el7.x86_64.rpm | cpio -id
587 blocks

root@ykla:~ # ./Wine-x86_64-opensuse.latest.AppImage
fuse: mount failed: File name too long

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information
open dir error: No such file or directory

I just try others AppImage like FreeCAD, and also not work.

root@ykla:~ # ./FreeCAD_0.19.3-Linux-Conda_glibc2.12-x86_64.AppImage 
fuse: mount failed: File name too long

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information
open dir error: No such file or directory
root@ykla:~ # 

I changed files name:

root@ykla:~ # mv FreeCAD_0.19.3-Linux-Conda_glibc2.12-x86_64.AppImage 1.AppImage
root@ykla:~ # ./1.AppImage 
/tmp/.mount_1.AppIRjhSaK/usr/bin/freecad: error while loading shared libraries: libFreeCADGui.so: cannot close file descriptor: Error 38
root@ykla:~ # ls
.ICEauthority				.local
.Xauthority				.login
.cache					.profile
.config					.shrc
.cshrc					.xsession-errors
.dbus					1.AppImage
.dmrc					Desktop
.history				Wine-x86_64-opensuse.latest.AppImage
.k5login				fuse-libs-2.9.2-11.el7.x86_64.rpm.1
root@ykla:~ # mv Wine-x86_64-opensuse.latest.AppImage 2.AppImage
root@ykla:~ # ./2.AppImage 
/tmp/.mount_2.AppIXJpR9R/bin/wine: error while loading shared libraries: /tmp/.mount_2.AppIXJpR9R/bin/wine: cannot close file descriptor: Error 38
root@ykla:~ # 

[probonopd]

I have it almost working now using an experimental build of helloSystem using FreeBSD 13.1-BETA1:

• Download https://github.com/helloSystem/ISO/releases/tag/experimental-13.1 and write the ISO to a USB stick
• Boot that
• System -> Applications -> Under Construction -> Install Debian Runtime
• You need to see
  
• (Possibly no longer needed?) sudo service linux stop && sudo service debian start
• Download https://github.com/AppImage/AppImageUpdate/releases/download/2.0.0-alpha-1-20220124/AppImageUpdate-x86_64.AppImage
• chmod +x ~/Downloads/AppImageUpdate-x86_64.AppImage
• ~/Downloads/AppImageUpdate-x86_64.AppImage

Results in:

/tmp/.mount_AppImawU1oh1/AppRun.wrapped: error while loading shared libraries: libappimageupdate-qt.so: cannot close file descriptor: Error 38

Running with truss:

linux_newstat("/tmp/.mount_AppImariVJnw/usr/bin/../lib/x86_64",0x7fffffffd780) ERR#-2 'No such file or directory'
linux_openat(0xffffff9c,0x7fffffffd6b0,0x80000,0x0) = 5 (0x5)
read(5,"\^?ELF\^B\^A\^A\0\0\0\0\0\0\0\0"...,832) = 832 (0x340)
linux_newfstat(5,0x7fffffffd780)                 = 0 (0x0)
linux_mmap2(0x0,0x2000,0x3,0x22,0xffffffff,0x0)  = 34378977280 (0x801259000)
linux_mmap2(0x0,0x210600,0x5,0x802,0x5,0x0)      = 34380709888 (0x801400000)
linux_mprotect(0x801410000,0x1ff000,0x0)         = 0 (0x0)
linux_mmap2(0x80160f000,0x2000,0x3,0x812,0x5,0xf000) = 34382868480 (0x80160f000)
close(5)                                         ERR#-38 'Function not implemented'
close(5)                                         ERR#-9 'Bad file descriptor'
/tmp/.mount_AppImariVJnw/AppRun.wrapped: error while loading shared libraries: libappimageupdate-qt.so: cannot close file descriptor: Error 38
writev(2,[{"/tmp/.mount_AppImariVJnw/AppRun."...,39},{": ",2},{"error while loading shared libra"...,36},{": ",2},{"libappimageupdate-qt.so",23},{": ",2},{"cannot close file descriptor",28},{": ",2},{"Error 38",8},{"\n",1}],10) = 143 (0x8f)
linux_exit_group(0x7f)
process exit, rval = 127

So clearly the AppImage does get mounted using FUSE since it knows about libappimageupdate-qt.so, but then something goes bad resulting in Error -38.

I also testeed this using SoulseekQt-2018-1-30-64bit.AppImage and am getting Error -38 as well.

Can you reproduce this @trasz?
Maybe some needed parts have not landed in FreeBSD 13.1-BETA1, after all?

[probonopd]

Using https://github.com/helloSystem/ISO/releases/tag/experimental-14.0-0.8.0_0H77 Live ISO based on FreeBSD 14, we can run AppImages that bundle everything without the need for any Linux compatibility libraries to be installed on the FreeBSD system using FUSE built into FreeBSD.

Tested with

• Run https://github.com/helloSystem/ISO/releases/tag/experimental-14.0-0.8.0_0H77 Live ISO
• Download https://github.com/probonopd/go-appimage/releases/download/continuous/appimagetool-711-x86_64.AppImage
• chmod +x Downloads/appimagetool-711-x86_64.AppImage
• ./Downloads/appimagetool-711-x86_64.AppImage --appimage-extract
• VERSION=TEST ./Downloads/appimagetool-711-x86_64.AppImage ./squashfs-root
• ./appimagetool-TEST-x86_64.AppImage

The above runs a Linux AppImage that bundle everything on a FreeBSD 14.0-CURRENT based system on which no Linux compatiblity libraries are installed, and uses that AppImage to create another AppImage, which also runs. (Eating our own dogfood.)

[probonopd]

Something strange is still going on. Getting ERR#-38 'Function not implemented', ERR#-9 'Bad file descriptor' when trying to run an AppImage on FreeBSD 14-CURRENT based experimental helloSystem ISOs directly (= without the need for a runappimage helper script).

To reproduce:

1. Run an experimental helloSystem 0.8.0 Live ISO (based on FreeBSD 14-CURRENT) (Download)
2. Download https://github.com/probonopd/go-appimage/releases/download/continuous/appimagetool-711-x86_64.AppImage (or later) and https://github.com/probonopd/Akira/releases/download/continuous/Akira-30-x86_64.AppImage
3. .runappimage '/home/Downloads/Desktop/Akira-30-x86_64.AppImage', works. Note that it runs despite an almost empty /compat/linux because everything (including ld-linux) is contained in the AppDir. However, we need the runappimage helper script which mounts the AppImage using the host's infrastructure rather than the Linuxulator, since the AppImage runtime itself is not statically built and hence requires ld-linux on the host, which we don't want and will change in the next steps
4. Extract the AppImage with unsquashfs --offset=188456 '/home/liveuser/Downloads/Akira-30-x86_64.AppImage'
5. Make a new Akira AppImage with the new static AppImage runtime that does not need ld-linux on the host: VERSION=NEW '/home/liveuser/Downloads/appimagetool-711-x86_64.AppImage' ./squashfs-root. Note that appimagetool itself is running from an AppImage just fine without the need for the runappimage helper script, whereas we will get issues when trying to run Akira without the runappimage helper script
6. Try to run the AppImage we just created without the runappimage helper script

./Akira-NEW-x86_64.AppImage 
Run experimental self-contained bundle
/tmp/.mount_Akira-mhoiHf/usr/bin/com.github.akiraux.akira: error while loading shared libraries: /tmp/.mount_Akira-mhoiHf/usr/bin/com.github.akiraux.akira: cannot close file descriptor: Error 38

Why are we getting this?

truss ./Akira-NEW-x86_64.AppImage
(...)
execve("/tmp/.mount_Akira-LBDDlo/lib64/ld-linux-x86-64.so.2",0x1a357ed56618,0x1a357ed56808) EJUSTRETURN
linux_brk(0x0)                                   = 17108992 (0x1051000)
linux_arch_prctl(0x3001,0x7fffffffbf90)          = 0 (0x0)
linux_openat(0xffffff9c,0x1050190,0x80000,0x0)   = 5 (0x5)
read(5,"\^?ELF\^B\^A\^A\0\0\0\0\0\0\0\0"...,832) = 832 (0x340)
linux_pread(0x5,0x7fffffffb5d0,0x310,0x361000)   = 784 (0x310)
linux_pread(0x5,0x7fffffffb5a0,0x20,0x338)       = 32 (0x20)
linux_pread(0x5,0x7fffffffb550,0x44,0x358)       = 68 (0x44)
linux_pread(0x5,0x7fffffffb4b0,0x310,0x361000)   = 784 (0x310)
linux_pread(0x5,0x7fffffffb190,0x20,0x338)       = 32 (0x20)
linux_pread(0x5,0x7fffffffb170,0x44,0x358)       = 68 (0x44)
linux_mmap2(0x0,0x365b80,0x1,0x802,0x5,0x0)      = 34378612736 (0x801200000)
linux_mprotect(0x801210000,0x351000,0x0)         = 0 (0x0)
linux_mmap2(0x801210000,0xae000,0x5,0x812,0x5,0x10000) = 34378678272 (0x801210000)
linux_mmap2(0x8012be000,0x6c000,0x1,0x812,0x5,0xbe000) = 34379390976 (0x8012be000)
linux_mmap2(0x80132a000,0x6000,0x3,0x812,0x5,0x129000) = 34379833344 (0x80132a000)
linux_mmap2(0x801330000,0x6d0,0x3,0x32,0xffffffff,0x0) = 34379857920 (0x801330000)
linux_mmap2(0x801561000,0x5000,0x3,0x812,0x5,0x361000) = 34382155776 (0x801561000)
close(5)                                         ERR#-38 'Function not implemented'
close(5)                                         ERR#-9 'Bad file descriptor'
/tmp/.mount_Akira-LBDDlo/usr/bin/com.github.akiraux.akira: error while loading shared libraries: /tmp/.mount_Akira-LBDDlo/usr/bin/com.github.akiraux.akira: cannot close file descriptor: Error 38
writev(2,[{"/tmp/.mount_Akira-LBDDlo/usr/bin"...,57},{": ",2},{"error while loading shared libra"...,36},{": ",2},{"/tmp/.mount_Akira-LBDDlo/usr/bin"...,57},{": ",2},{"cannot close file descriptor",28},{": ",2},{"Error 38",8},{"\n",1}],10) = 195 (0xc3)
linux_exit_group(0x7f)
process exit, rval = 127

What is going on? What is causing the ERR#-38 'Function not implemented' in this case?

[time-killer-games]

If you happen to want to add support for this on other *BSD's and/or SunOS, I have a way to get the appimage image path written for each of these so you can easily set the $APPIMAGE environment variable:

https://github.com/CoreNGS/api/blob/61276b2a6fa9829246696ba206ecc767e9301d48/apifilesystem/filesystem.cpp#L529-L686

OpenBSD in particular was a struggle to figure out a semi-reliable means, as there is not a OS-provided API to do this. As it stands, the code I have can get the executable path to every executable running on a fresh install of OpenBSD running Xorg.