Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Error building Appimage after latest update #272

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
namanlp opened this issue Feb 19, 2024 · 8 comments
Open

Error building Appimage after latest update #272

namanlp opened this issue Feb 19, 2024 · 8 comments

Comments

@namanlp
Copy link

namanlp commented Feb 19, 2024

Hi there!

After the latest Arch Linux package updates, the LinuxDeploy is having errors, and can't build at all. The error is as shown below

ERROR: Strip call failed: /tmp/appimage_extracted_0299051fc9707c0ee1f44f4a07981aee/usr/bin/strip: tauri-example.AppDir/usr/lib/libffi.so.8: unknown type [0x13] section `.relr.dyn'

/tmp/appimage_extracted_0299051fc9707c0ee1f44f4a07981aee/usr/bin/strip: Unable to recognise the format of the input file `tauri-example.AppDir/usr/lib/libffi.so.8'

And same errors for a couple of libraries, like libpango, libgstreamer , libgsttag , libgsttranscoder etc.

I have tried

  • Installing a new system and updating that.
  • Downgrading these packages fixes the issue.

Any insight on this issue?
@namanlp
Copy link
Author

namanlp commented Feb 19, 2024

Also, using NO_STRIP=true environment variable compiles fine without errors

@hdclark
Copy link
Contributor

hdclark commented Feb 20, 2024 •
edited
Loading

Note this isn't strictly related to libffi.so.8, libpangoft2-1.0.so.0 has the same issue.

The current linuxdeploy CI release succeeds on Debian stable, but fails when stripping on Arch Linux.

hdclark pushed a commit to hdclark/DICOMautomaton that referenced this issue Feb 20, 2024
CI: AppImage: disable linuxdeploy stripping.
35d7c4c 
Found an upstream bug report. See linuxdeploy/linuxdeploy#272 for context.
@namanlp
Copy link
Author

namanlp commented Feb 21, 2024

Yeah, as I mentioned in the bug report itself, it is having issue with a bunch of libraries, so I guess it is issue with the LinuxDeploy itself.

Regarding Debian, it is not an issue right now, because the libraries are not updated for Debian yet. Downgrading only these libraries on Arch work fine as well. After a few weeks, the issue will be faced on Debian as well.

@doums doums mentioned this issue Feb 21, 2024
Open
@sonic2kk sonic2kk mentioned this issue Mar 20, 2024
Closed
@vorporeal
Copy link
Contributor

Should linuxdeploy be using the host system's strip instead of a bundled one? If it's working with host system libraries, using a bundled strip (potentially from a different toolchain) is prone to issues like this.

@namanlp
Copy link
Author

namanlp commented Apr 9, 2024

YES!

@FrancoRATOVOSON
Copy link

Also, using NO_STRIP=true environment variable compiles fine without errors

Sorry, how do I use it ? Where do I put NO_STRIP=true ?

@hdclark
Copy link
Contributor

hdclark commented Apr 22, 2024

@FrancoRATOVOSON Define it as an environment variable before running linuxdeploy. Here is an example where I unpack the linuxdeploy AppImage and then define NO_STRIP as a temporary environment variable for the invocation: hdclark/DICOMautomaton@35d7c4c

@esmersmith esmersmith mentioned this issue May 8, 2024
Open
nikp123 added a commit to nikp123/xava that referenced this issue Jul 10, 2024
@nikp123
[bugfix] Fix Archlinux AppImage CI
05ee29c 
Disabling stripping seems to be the issue, as per:
linuxdeploy/linuxdeploy#272
Optiligence added a commit to knossos-project/knossos that referenced this issue Aug 27, 2024
@Optiligence
//linuxdeploy/linuxdeploy#272 workaround
0ac3a80
Optiligence added a commit to knossos-project/knossos that referenced this issue Aug 27, 2024
@Optiligence
älinuxdeploy/linuxdeploy#272 workaround
ee28658
Optiligence added a commit to knossos-project/knossos that referenced this issue Aug 27, 2024
@Optiligence
älinuxdeploy/linuxdeploy#272 workaround
cc7cd0d
Optiligence added a commit to knossos-project/knossos that referenced this issue Aug 28, 2024
@Optiligence
linuxdeploy/linuxdeploy#272 workaround
2668957
@ms0503 ms0503 mentioned this issue Sep 16, 2024
Open
@tidux tidux mentioned this issue Nov 20, 2024
Closed
@briaguya-ai briaguya-ai mentioned this issue Dec 20, 2024
Closed
@arteme
Copy link

arteme commented Jan 9, 2025

Should linuxdeploy be using the host system's strip instead of a bundled one? If it's working with host system libraries, using a bundled strip (potentially from a different toolchain) is prone to issues like this.

This is rather straight-forward to do locally. Linuxdeploy already has the logic to use strip from $PATH it is not packaged together with the linuxdeploy binary (

linuxdeploy/src/core/appdir.cpp

Line 379 in 0473bab

// by default, try to use a strip next to the linuxdeploy binary
). So, we can just remove it and repackage the AppImage:

wget https://github.com/linuxdeploy/linuxdeploy/releases/download/continuous/linuxdeploy-x86_64.AppImage
chmod 755 ./linuxdeploy-x86_64.AppImage
./linuxdeploy-x86_64.AppImage --appimage-extract
rm squashfs-root/usr/bin/strip
squashfs-root/plugins/linuxdeploy-plugin-appimage/appimagetool-prefix/usr/bin/appimagetool -gn squashfs-root/
rm -r squashfs-root

There, now you have linuxdeploy-x86_64.AppImage that uses the system strip binary!

Now, your linuxdeploy should work if it previously failed with errors like:

Calling strip on library /home/arteme/.../foobar.AppDir/usr/lib/libsharpyuv.so.0
ERROR: Strip call failed: /tmp/appimage_extracted_03fe9e13e6db9ad49ecf0db958674699/usr/bin/strip: /home/arteme/.../foobar.AppDir/usr/lib/libsharpyuv.so.0: unknown type [0x13] section `.relr.dyn'
/tmp/appimage_extracted_03fe9e13e6db9ad49ecf0db958674699/usr/bin/strip: Unable to recognise the format of the input file `/home/arteme/.../foobar.AppDir/usr/lib/libsharpyuv.so.0'

For those still in doubt, if we do sudo rm /usr/bin/strip (...don't do that! I did it so you don't have to...), you'd see linuxdeploy instead fail with errors like:

Calling strip on library /home/arteme/.../foobar.AppDir/usr/lib/libsharpyuv.so.0
ERROR: Strip call failed: terminate called after throwing an instance of 'std::runtime_error'
  what():  exec() failed: No such file or directory

Garmelon added a commit to Garmelon/gedaechtnas that referenced this issue Feb 13, 2025
@Garmelon
Disable bundling in build
6fb900f 
For one, it fails on arch linux, which is what I'm developing on:
tauri-apps/tauri#8929
tauri-apps/tauri#11149
linuxdeploy/linuxdeploy#272

At the moment, I plan on distributing Linux and Windows binaries as well
as an APK for Android. If I'll ever include any bundles in the CI, they
can be manually triggered using --bundles.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@arteme @vorporeal @hdclark @FrancoRATOVOSON @namanlp