darealshinji / linuxdeploy-plugin-checkrt Goto Github PK

On xubuntu-16.04.1-desktop-amd64.iso with https://github.com/probonopd/audacity/releases/download/checkrt/Audacity-63de7f0-x86_64.AppImage:

ERROR: ld.so: object '/tmp/.mount_AudaciivUspk/usr/optional/exec.soA' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/tmp/.mount_AudaciivUspk/usr/optional/exec.soA' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/tmp/.mount_AudaciivUspk/usr/optional/exec.soA' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/tmp/.mount_AudaciivUspk/usr/optional/exec.soA' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/tmp/.mount_AudaciivUspk/usr/optional/exec.soA' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

Where is the extra "A" coming from?

Interesting: If I run

./Audacity-63de7f0-x86_64.AppImage --appimage-extract
./squashfs-root/AppRun

then I do not see these messages.

Related to #24. When source-ing the script from any other location than AppRun, the script cannot properly determine the path to its auxiliary files.

Now this is obviously just a problem with linuxdeploy-plugin-native_packages which cannot use AppRun technically at this point. It should be possible to implement a chain that first attempts to calculate a path based on $APPDIR (if available), then fall back to $BASH_SOURCE and finally $0.

Per default, AppRun.sh compares the symbols of the system libstdc++ and the packaged one.
I'm not sure how portable and/or correct this is, especially with script-based applications, but isn't it enough to compare the symbols of the application?
e.g.

  sym_app=$(tr '\0' '\n' < "$exec" | grep -e '^GLIBCXX_3\.4' | sort -V | tail -n1)

This could partially solve e.g. mesa issues like sgsaenger/vipster#30

Not a bug, but wanted to say thanks for this.
I recently implemented it in my build, and now the software works without the users having to upgrade their gcc. It doesn't break modern Linux either.

Extremely clean, extremely effective. Thanks so much!

Using c/c++ on ubuntu, getcwd should return the path where AppImage is called. But the return is always FUSE mounted.

Ob Xubuntu 16.04 using https://github.com/probonopd/audacity/releases/download/continuous/Audacity-8724a5a-x86_64.AppImage:

me@host:~$ export APPIMAGE_CHECKRT_DEBUG=1
me@host:~$ '/home/me/Downloads/Audacity-8724a5a-x86_64(1).AppImage' 
APPIMAGE_CHECKRT>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ==> GLIBCXX_3.4.21 (21)
APPIMAGE_CHECKRT>> ./optional/libstdc++/libstdc++.so.6 ==> GLIBCXX_3.4.24 (24)

APPIMAGE_CHECKRT>> optional_ld_library_path: /tmp/.mount_Audacin3QZoY/usr/optional/libstdc++:
optional_ld_preload: LD_PRELOAD=/tmp/.mount_Audacin3QZoY/usr/optional/exec.so

But then, when I want to select Help -> Quick Help, I get:

(...)
APPIMAGE_CHECKRT>> >>> custom execve()!
APPIMAGE_CHECKRT>> >>> custom execve()!
APPIMAGE_CHECKRT>> >>> custom execve()!
/usr/lib/firefox/firefox: relocation error: /usr/lib/firefox/firefox: symbol _ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE4copyEPcmm, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference

Note that /usr/lib/firefox/firefox is outside of the AppImage, hence our private libstdc++ should not be used for it.

On opensuse tumbleweed, from https://get.opensuse.org/tumbleweed/

litrace opensuse issue.txt

strace.txt

The usr/optional/cxx/libstdc++.so.6 is compiled with GCC11, that one loads, but then when checkrt goes to check the local library, the dlmopen never returns.

Would it be possible to make a dummy library that gets loaded instead of libstdc++, then determines whether the system or bundled libstdc++ should be loaded, and then would load that one in turn? This would greatly simplify using this, as it would remove the need for a custom AppRun, bash script or similar wrapper.

Background: In linuxdeployqt we have moved away from AppRun binaries or scripts and just use a symlink to the main executable, as we think this is a much cleaner solution.

Hi,

On Yuzu actually Appimage build have been update but actually some issues is effective.
Update : https://github.com/yuzu-emu/yuzu/pull/6667

1. issue : https://github.com/yuzu-emu/yuzu/issues/8897
2. issue : https://github.com/yuzu-emu/yuzu/issues/8921

In two cases we probably want to use your script for check conformity of appimage.
What do you think about the idea to check for example :

./usr/bin/$exec "$*"
vs
exec ./usr/bin/yuzu "$@"

Best Regards

As discovered investigating issue #20 , there seems to be a bug in the way checkrt searches for the addresses of the .strtab and .dynstr sections.

Reading lines 147-165, it seems that finding either the .strtab section or the .dynstr section stops the search loop with a break statement.
This means that if a library contains both .strtab and .dynstr, only one of the addresses will be set, while the other address will stay at the value set at lines 143-144 .

I discovered this by accident by making checkrt check libstdc++.so.6 before libgcc_s.so.1, swapping lines 374-378 with lines 380-384 (and moving the int var).
Doing that makes checkrt segfault at the strncmp at line 194.

Deleting the two breaks at line 157 and line 163 fixes the segfault and checkrt runs successfully.

It's not immediately obvious how to actually use this in conjunction with linuxdeployqt.AppImage to make an AppImage that works with a newer libstdc++ version.

I recently helped debug a problem that occurred with https://github.com/linuxdeploy/linuxdeploy-plugin-native_packages/. This output plugin deploys autogenerated helper scripts in /usr/bin for every desktop entry in the AppImage to imitate classic packaging.

There is no technical need for the files this plugin generates during build time to be located within that hooks directory. We should move the files outside of there, e.g., one level up.

Of course, the output plugin will receive some improvements to filter out seemingly incompatible files. But I'd also like to narrow the plugin specification to limit the directory to source-able shell scripts.

Please consider making some kind of releases. linuxdeploy for instance uses point releases based on the current date. This allows users to use a known-working state. Also, it allows for a/b testing of changes.

Your GitHub actions CI pipeline already supports this use case because it uses pyuploadtool to upload the binaries. All you need to do is push a tag, the CI handles the creation of the release on GitHub along with a binary built from this tag.

While this works reasonably well, it's an antipattern to include autogenerated bits in a repository.

You could use a tool like pyuploadtool to create a continuous GitHub release with the generated file.

I can implement a basic workflow if you like the idea.

I am testing this to make a C++14 application run on Debian Jessie. Trying to run my AppImage displays sh: 1: ldconfig: not found error. The script then fails to load the bundled libstdc++.so and the application stops with a CXXABI error.

ldconfig is located in /sbin which is not in the path of regular users. With a PATH including /sbin, the AppImage starts correctly.

When I build appimage with AppImageKit-checkrt for a FUSE application and then run it, I get an error:

fusermount: old style mounting not supported

Complete MWE: https://gist.github.com/vodka2/44e1a40c3bcfb2899b21bdcd555ba8eb
If comment the first 4 lines in build.sh or if I run the appimage as root, no error happens. I'm using Arch Linux.
What is wrong with this example?

Using xubuntu-16.04.1-desktop-amd64.iso and Audacity-dc63bfe-x86_64.AppImage from https://github.com/probonopd/audacity/releases, when I select Help -> "Check for updates", it fails:

"Failed to execute default Web Browser.
input/output error"

On the command line I get:

/usr/lib/firefox/firefox: relocation error: /usr/lib/firefox/firefox:
symbol _ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE4copyEPcmm,
version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference

I suspect this to be a side effect of using AppImageKit-checkrt.

This is a workaround:

./Audacity-dc63bfe-x86_64.AppImage --appimage-extract
rm squashfs-root/usr/optional/libstdc++/libstdc++.so.6
./squashfs-root/AppRun

Wrong paths in 126fa22 result in plugin not being loaded.