AppImage versions fail to run - execv error: No such file or directory

[SherifOne]

Trying to run the AppImage (i.e. ./brewtarget-5.0.2.AppImage ) of the latest release - (file brewtarget-5.0.2.AppImage ) fails with
"execv error: No such file or directory"
Same issue also exists on brewtarget-5.0.1.AppImage

I am running on Manjaro Linux (arch based):
For ref, here is output of uname -a
6.12.68-1-MANJARO #1 SMP PREEMPT_DYNAMIC Fri, 30 Jan 2026 23:06:15 +0000 x86_64 GNU/Linux

[matty0ung]

Sorry to hear you're having problems. I've had a quick look and I think I can see what's wrong. I'll have to dig back through the packaging code to work out how to fix it (because it's not immediately obvious).

Specifically, if you unpack the AppImage by running ./brewtarget-5.0.2.AppImage --appimage-extract, you'll see in the squashfs-root directory that there's a one-line script called AppRun that is trying to run $APPDIR/usr/bin/brewtarget(base) when it should be trying to run $APPDIR/usr/bin/brewtarget (or else we should rename ./usr/bin/brewtarget to ./usr/bin/brewtarget(base)).

[SherifOne]

Wow - quick response!
Though I don't quite follow...
When extracted the AppRun file reads
#!/bin/bashexec $APPDIR/usr/bin/brewtarget
(no mention of "(base)")

[matty0ung]

Ah, sorry, you're right. I was misreading the output. (The first line of the prompt in the shell I opened is (base)!)

In that case it's more puzzling. On my machine, if I execute ./usr/bin/brewtarget directly in the unpacked AppImage, it runs fine. So I'm now wondering if it's something that means $APPDIR isn't getting set.

If you can uncover any more diagnostics or clues on your system, then I'll be glad to have them.

[SherifOne]

Ah...
If I execute ./usr/bin/brewtarget directly in the unpacked AppImage I see this:
./usr/bin/brewtarget: error while loading shared libraries: libxerces-c-3.2.so: cannot open shared object file: No such file or directory

[matty0ung]

Thanks -- that's helpful. Looks like there's a step missing or misconfigured in our AppImage creation and it's not picking up the libraries from the build machine. I'll dig into this, hopefully in the next week or two.

[matty0ung]

The errors above should be fixed in 5.0.3. If you get a chance to try again, that would be great. If you hit any other problems, please don't hesitate to raise an issue.

[SherifOne]

Progress... but now fails with.
/tmp/.mount_brewtahFdnBB/usr/bin/brewtarget: error while loading shared libraries: libxerces-c-3.2.so: cannot open shared object file: No such file or directory

[matty0ung]

Thanks for letting me know. That's a bit more puzzling, as libxerces-c-3.2.so is in the usr/lib subdirectory of the AppImage bundle. My guess is that we haven't done the right things to make the app load its libraries from a relative path. I'll do some more investigation.

[matty0ung]

OK, I think I understand what needs to be fixed. It should just be a question of adding another RUNPATH directory to the executable. If you have patchelf installed, you can actually do this directly to the binary. Eg, assuming you are in the top directory of the mounted/expanded AppImage:

$ cd usr/bin
$ patchelf --add-rpath '$ORIGIN/../lib' brewtarget
$ patchelf --print-rpath brewtarget
$ORIGIN/../lib
$ ./brewtarget

Sorry for the back-and-forth on this. It's a bit hard to test AppImage on my machine because I already have all the shared library dependencies installed in system-wide locations (so the linker/loader always finds them even if it didn't find them inside the AppImage).

Anyway, I'll do a fix to the build system for this, but if you get a chance to test the workaround above, it would be great to know whether everything works or whether it uncovers any other issue.

[SherifOne]

Hi.
Thanks for the prompt action on this.
Yes... that moves it on, but just to another point of failure. So it does look like there is a problem loading dependencies.
What I see now is:
./brewtarget: error while loading shared libraries: libicudata.so.70: cannot open shared object file: No such file or directory

[matty0ung]

OK, that's progress nonetheless. I can see what's happening. The program is now loading libxalan-c.so.112 from the right location, and libxalan-c.so.112 is trying to load its own dependencies, including libicudata.so.70. That library is in the usr/lib directory, but we haven't told the linker/loader to look for it there.

You might be able to do a short-term fix by setting the LD_LIBRARY_PATH variable. But the proper fix is either for us to set that variable in the AppRun script (simple) or to add a RUNPATH to all the libraries we ship in the usr/lib directory (slightly more work but very doable).

[90percentbrewer]

New version (5.0.3) installs and runs on my macMini running 26.2