AppImage / AppImageKit

Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat
http://appimage.org
Other
8.71k stars 559 forks source link

Execute AppImage file, get the error message "execv error: No such file or directory" #508

Closed HungerKiller closed 6 years ago

HungerKiller commented 6 years ago

I download the 'appimagetool-x86_64.AppImage'. And use it to make my appimage file successfully. However, when I execute 'myfile.AppImage' by typing "./myfile.AppImage", it returns:

TheAssassin commented 6 years ago

Is there an AppRun file in the AppDir? Is that file executable?

You should follow good practices and provide an MWE that has the bug, e.g., by uploading your AppImage somewhere and providing a link. Otherwise, we're just guessing wildly here.

probonopd commented 6 years ago

Which application are you packaging, and is the script you are using to do this available?

probonopd commented 6 years ago

@HungerKiller?

TheAssassin commented 6 years ago

Closing due to inactivity. Please reopen in case you still think this is a bug.

HungerKiller commented 6 years ago

Thank you for your anwsers and sorry for inactivity. I have used other way to package the software. I cant upload the app recently, because it is a entreprise project, and the time is very busy for the projet. I will try with a small personal project later. Thanks alot and sry...

HungerKiller commented 6 years ago

Here, I do a summary. ----------------The context---------------- Write code in QT5.9.1 and compile the code on mode Release. In the folder "Release", it contains all files needed by program. If double-click the executable file, the program can be launch. ----------------What I have done to produce the error---------------- Then use "appimagetool-x86_64.AppImage" to package the program: "./appimagetool-x86_64.AppImage Release/". It can produce a .appimage file, but when execute it, the error is "No such file or directory" ----------------What I have done to package the program successfully---------------- Use the tool "linuxdeployqt-continuous-x86_64.AppImage": "./linuxdeployqt-continuous-x86_64.AppImage Release/MyProgram". It can package the program successfully, but the package is not only one appimage file, it is a folder. Copy the folder to other PC, it works.

probonopd commented 6 years ago

I think what you are trying to do is ./linuxdeployqt-continuous-x86_64.AppImage Release/MyProgram -appimage? By the way, the linuxdeployqt project is located at https://github.com/probonopd/linuxdeployqt. Be sure to check the documentation at https://github.com/probonopd/linuxdeployqt#usage.

HungerKiller commented 6 years ago

Yes, exactly!

monocasual commented 6 years ago

@probonopd I'm facing the same error while trying to run a previously AppImage'd app (this one for the record).

I'm following the "manual steps" described here. The output of appimagetool-x86_64.AppImage <appdir> seems successful, except for a couple of warnings:

WARNING: appstreamcli is missing, please install it if you want to use AppStream metadata
Using architecture x86_64
/home/mcl/projects/giada/giada-appimage/Giada.AppDir should be packaged as Giada-x86_64.AppImage
WARNING: AppStream upstream metadata is missing, please consider creating it
         in usr/share/metainfo/giada.appdata.xml
         Please see https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
         for more information.
Generating squashfs...
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on Giada-x86_64.AppImage, block size 131072.
[===============================================================================================================================================================================/] 79/79 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
    compressed data, compressed metadata, compressed fragments, compressed xattrs
    duplicates are removed
Filesystem size 3912.68 Kbytes (3.82 Mbytes)
    40.87% of uncompressed filesystem size (9572.54 Kbytes)
Inode table size 476 bytes (0.46 Kbytes)
    64.06% of uncompressed inode table size (743 bytes)
Directory table size 188 bytes (0.18 Kbytes)
    73.15% of uncompressed directory table size (257 bytes)
Xattr table size 436 bytes (0.43 Kbytes)
    72.79% of uncompressed xattr table size (599 bytes)
Number of duplicate files found 0
Number of inodes 13
Number of files 8
Number of fragments 2
Number of symbolic links  1
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 4
Number of ids (unique uids + gids) 1
Number of uids 1
    root (0)
Number of gids 1
    root (0)
Embedding ELF...
Marking the AppImage as executable...
Success

Please consider submitting your AppImage to AppImageHub, the crowd-sourced
central directory of available AppImages, by opening a pull request
at https://github.com/AppImage/appimage.github.io

I also double-checked the absence of hard-coded paths in the binary that would prevent it from being relocateable. Running the appImage's version always yields execv error: No such file or directory.

Here is the .AppImage dir I'm currently using: giada-appimage.zip

probonopd commented 6 years ago

Multiple issues:

  1. Not all dependencies are bundled, e.g.,
xubuntu@xubuntu:~$ /home/xubuntu/Downloads/Giada.AppDir/AppRun-x86_64
giada: error while loading shared libraries: libfltk.so.1.3: cannot open shared object file: No such file or directory

Checking for additional missing libraries yields:

xubuntu@xubuntu:~$ export LD_LIBRARY_PATH=/home/xubuntu/Downloads/Giada.AppDir/usr/lib/ ; find /home/xubuntu/Downloads/Giada.AppDir/ -type f -executable -exec ldd {} \; | grep "not found"
    libfltk.so.1.3 => not found
    librtmidi.so.4 => not found
    libjansson.so.4 => not found

These libraries, as well as their dependencies, need to be bundled as well.

It may be much easier to use https://github.com/probonopd/linuxdeployqt instead, which would do the required work automatically for you. Please check out the Travis CI example in its documentation; you should be able to copy-and-paste it almost 1:1 and go from there.

  1. AppRun-x86_64 needs to be renamed to AppRun
monocasual commented 6 years ago

@probonopd thanks for your quick reply (and sorry for my late one)! You are right, there are still some missing dependencies. I'll also look into https://github.com/probonopd/linuxdeployqt more closely.

shivangsgangadia commented 6 years ago

Hey! I'm trying to make an AppImage of a C++ executable which also uses glade XML files for GTK+ user interface. When I try to run the executable directly, it runs fine, but when I try to use AppRun it fails to locate the glade files. `(QuizTech:10130): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(QuizTech:10130): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(QuizTech:10130): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(QuizTech:10130): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(QuizTech:10130): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(QuizTech:10130): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(QuizTech:10130): Gtk-CRITICAL **: gtk_widget_show_all: assertion 'GTK_IS_WIDGET (widget)' failed `

Also the appimage created does not execute with: execv error: No such file or directory I have use appimagetool to create it. The source code for my little project is available at github.com/shivangsgangadia/quiz_tech

Here is my appdir: QuizTech.AppDir.zip

probonopd commented 6 years ago
me@host:~$ strace -eopen -f /home/me/Downloads/QuizTech.AppDir/AppRun 2>&1 | grep glade
open("login.glade", O_RDONLY)           = -1 ENOENT (No such file or directory)

suggests that this is trying to load login.glade from the current working directory. This is not going to work. You need to make it load from a path relative to the main executable.

shivangsgangadia commented 6 years ago

I tried changing the file name from "login.glade" to a path "./login.glade" inside the source code. Still no improvement.

probonopd commented 6 years ago

Again, you need to make it load from a path relative to the main executable. Not relative to . (currrent working directory = where the user is in at the moment).

shivangsgangadia commented 6 years ago

Got it solved using getpwd(). The path must be relative to the AppRun executable. Thanks a lot!

dvrsv commented 4 years ago

For me the problem was somehow in AppRun the second line of code got tangled with the #!/bin/bash on the first line.

pktiuk commented 2 years ago

I had a similar problem, but I found solution here: https://github.com/OpenShot/openshot-qt/issues/93#issuecomment-198639916

Running chmod a+x ./activitywatch/AppRun helped.
To be honest, I think, that linuxdeploy should add these flags to this file. It would be a minor change in code but it could prevent some problems with packaging.

probonopd commented 2 years ago

The AppRun file permissions should be 0755. linuxdeploy just converts a working AppDir to an AppImage. Without the correct permissions you don't have a working AppDir to begin with. There are higher-level tools which set the permissions on this file; linuxdeploy is a low-level tool that most users should not be using directly.

TheAssassin commented 2 years ago

I had a similar problem, but I found solution here: OpenShot/openshot-qt#93 (comment)

Running chmod a+x ./activitywatch/AppRun helped. To be honest, I think, that linuxdeploy should add these flags to this file. It would be a minor change in code but it could prevent some problems with packaging.

You're right, and I've always wanted to do this. I was about to ask you to create an issue, but let's just fix this once and for all.

There are higher-level tools which set the permissions on this file; linuxdeploy is a low-level tool that most users should not be using directly.

A little convenience doesn't hurt IMO. This should be the final step of the AppRun deployment process.

probonopd commented 2 years ago

A little convenience doesn't hurt IMO.

True ;-)

Gold-Samiar commented 1 year ago

I found it is permission problem on linux. fuse2 may be solve this problem but it is good idea if we set permissions before pack.