APPRUN_ERROR: No such file or directory due to broken symlink

[alberic89]

My AppImage (see the recipe in attachment) is executable only on the build machine.
If I try to run on other OS or machine, I got the error APPRUN_ERROR: No such file or directory.
In the AppRun.env file, the last line is APPDIR_LIBC_LINKER_PATH={'lib/ld-linux-aarch64.so.1'}
It's refer to a symlink who points to aarch64-linux-gnu/ld-2.31.so, a broken symlink who points to ld-2.31.so, but the right of location of ld-2.31.so is runtime/compact/lib/aarch64-linux-gnu/ld-2.31.so.
How to fix this ?

OS : Raspberry Pi OS
architecture : arm64 (aarch64)
appimage-builder version : latest pip standard installation
AppImageBuilder.yml.txt
AppRun.env.txt

[damoclark]

hi @perrito666

I am experiencing the same error as @alberic89 except that I see no broken symlinks as @alberic89 describes in my aarch64 build. On checking all the path variables and files located in those paths, I am not finding any broken links.

I also have an identical build for the x86_64 architecture that works perfectly fine. All I did was compile the source code on an arm64 computer (Raspberry Pi 5B), and copied it over to the x86_64 machine I am using. Then I updated yaml file so the apt platform uses an arm64 repository, and then and built the image copying the compiled source code into the AppDir, just as I did for the x86 code. The arm appimage builds no problem.

However, when I execute it on the arm computer, I get APPRUN_ERROR: No such file or directory.

I noted the debian bookworm apt repositories used on the arm machine where I compiled the source, and used the exact same apt repositories under the apt section of the yaml file. So the appimage build uses the same repo packages to build the image as was used to compile the software.

I can run the compiled arm code natively on the arm machine okay.

I've cross-checked the files between the two images by extracting them both to see what differences there are. I've attached a path diff (at very bottom) so you can see how the x86 and arm squashfs images compare. I noticed that the ld-linux-aarch64.so.1 and the ld-linux-x86-64.so.2 are located in different paths between the two appimages. I wonder whether this might be the cause.

environments

aarch64 OS: Raspberry Pi OS (Debian Bookworm 12.4)
x86_64 OS: Ubuntu 22.04
appimage-builder: appimage-builder-1.1.1.dev32+g2709a3b-x86_64.AppImage

commands used

FLOM_INSTALL_PREFIX_DIR=/tmp/flom FLOM_VERSION=1.7.1 appimage-builder-1.1.1.dev32+g2709a3b-x86_64.AppImage --recipe <recipe filename>

x86 yaml

# Command to build an appimage for flom 1.7.1
# cd flom-1.7.1
# make clean
# ./configure --prefix=/tmp/flom --disable-{php,perl,python,java}
# make -j2
# make install
#
# FLOM_INSTALL_PREFIX_DIR=/tmp/flom FLOM_VERSION=1.7.1 appimage-builder-1.1.1.dev32+g2709a3b-x86_64.AppImage --recipe flom-aarch64.yml
#
version: 1
script:
  # Remove any previous build
  - rm -rf AppDir  || true
  # Make usr dir
  - "mkdir -p AppDir/usr"
  # Copy the install location for flom into appdir with everything under usr
  - 'tar cvf - -C "{{FLOM_INSTALL_PREFIX_DIR}}" . | tar xf - -C AppDir/usr/'
 
AppDir:
  path: ./AppDir

  app_info:
    id: org.tiian.flom
    name: flom
    icon: utilities-terminal
    version: "{{FLOM_VERSION}}"
    # Set the executable as entry point
    exec: usr/bin/flom

  apt:
    arch: "amd64"
    sources:
      - sourceline: 'deb http://archive.ubuntu.com/ubuntu/ jammy main restricted universe multiverse'
        key_url: 'http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x871920D1991BC93C'

    include:
      - fuse3 # So flom can mount its state fuse filesystem
      - openssl # For encryption between client/server
      - dbus # Not sure what this is used for
    exclude: []

  files:
    exclude: 
      - "usr/share/*"
      - "usr/include/*"
      
  runtime:
    path_mappings:
      # The compiled default for flom.conf is remapped to somewhere sensible
      - "{{FLOM_INSTALL_PREFIX_DIR}}/etc/flom.conf:/usr/local/etc/flom.conf"

  test:
    fedora:
      image: appimagecrafters/tests-env:fedora-30
      command: ./AppRun
      use_host_x: true
    debian:
      image: appimagecrafters/tests-env:debian-stable
      command: ./AppRun
      use_host_x: true
    arch:
      image: appimagecrafters/tests-env:archlinux-latest
      command: ./AppRun
      use_host_x: true
    centos:
      image: appimagecrafters/tests-env:centos-7
      command: ./AppRun
      use_host_x: true
    ubuntu:
      image: appimagecrafters/tests-env:ubuntu-xenial
      command: ./AppRun
      use_host_x: true

AppImage:
  # Dont know what this means yet - need to figure it out
  update-information: guess
  sign-key: None
  arch: "x86_64"

arm yaml

# Error:
# APPRUN_ERROR: No such file or directory
# https://github.com/AppImageCrafters/appimage-builder/issues/304
#
# Command to build an appimage for flom 1.7.1
# cd flom-1.7.1
# make clean
# ./configure --prefix=/tmp/flom --disable-{php,perl,python,java}
# make -j2
# make install
#
# FLOM_INSTALL_PREFIX_DIR=/tmp/flom FLOM_VERSION=1.7.1 appimage-builder-1.1.1.dev32+g2709a3b-x86_64.AppImage --recipe flom-aarch64.yml
#
version: 1
script:
  # Remove any previous build
  - rm -rf AppDir  || true
  # Make usr dir
  - "mkdir -p AppDir/usr"
  # Copy the install location for flom into appdir with everything under usr
  - 'tar cvf - -C "{{FLOM_INSTALL_PREFIX_DIR}}" . | tar xf - -C AppDir/usr/'
 
AppDir:
  path: ./AppDir

  app_info:
    id: org.tiian.flom
    name: flom
    icon: utilities-terminal
    version: "{{FLOM_VERSION}}"
    # Set the executable as entry point
    exec: usr/bin/flom

  apt:
    arch: "arm64"
    sources:
      # arm sources and key_url from
      # https://ftp-master.debian.org/keys.html
      - sourceline: 'deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware'
        key_url: 'https://ftp-master.debian.org/keys/archive-key-12.asc'
      - sourceline: 'deb http://deb.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware'
        key_url: 'https://ftp-master.debian.org/keys/archive-key-12-security.asc'
      - sourceline: 'deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware'
        key_url: 'https://ftp-master.debian.org/keys/release-12.asc'
      - sourceline: 'deb http://archive.raspberrypi.com/debian/ bookworm main'
        key_url: 'http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x82B129927FA3303E'

    include:
      - fuse3 # So flom can mount its state fuse filesystem
      - openssl # For encryption between client/server
      - dbus # Not sure what this is used for
    exclude: []

  files:
    exclude: 
      - "usr/share/*"
      - "usr/include/*"
      
  runtime:
    path_mappings:
      # The compiled default for flom.conf is remapped to somewhere sensible
      - "{{FLOM_INSTALL_PREFIX_DIR}}/etc/flom.conf:/usr/local/etc/flom.conf"

  test:
    fedora:
      image: appimagecrafters/tests-env:fedora-30
      command: ./AppRun
      use_host_x: true
    debian:
      image: appimagecrafters/tests-env:debian-stable
      command: ./AppRun
      use_host_x: true
    arch:
      image: appimagecrafters/tests-env:archlinux-latest
      command: ./AppRun
      use_host_x: true
    centos:
      image: appimagecrafters/tests-env:centos-7
      command: ./AppRun
      use_host_x: true
    ubuntu:
      image: appimagecrafters/tests-env:ubuntu-xenial
      command: ./AppRun
      use_host_x: true

AppImage:
  # Dont know what this means yet - need to figure it out
  update-information: guess
  sign-key: None
  arch: "aarch64"

path diff

appimage-diff.html.zip

[perrito666]

looking at this, thanks for the report

[damoclark]

Some further info that might help.

Built an appimage for aarch64, but instead using Ubuntu 22.04 - the same OS and version as the x86_64 build. In other words, Ubuntu 22.04 instead of Debian 12.4

It had same error.

Looking specifically at the location of the ld-linux-aarch64.so.1 file, the two aarch64 images (both Ubuntu and Debian) are the same.

aarch64 Debian

find squashfs-root/ -name ld-\* -print
squashfs-root/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1
squashfs-root/lib/ld-linux-aarch64.so.1 -> aarch64-linux-gnu/ld-linux-aarch64.so.1
squashfs-root/runtime/default/lib/ld-linux-aarch64.so.1 -> /lib/ld-linux-aarch64.so.1

aarch64 Ubuntu

squashfs-root/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1
squashfs-root/lib/ld-linux-aarch64.so.1 -> aarch64-linux-gnu/ld-linux-aarch64.so.1
squashfs-root/runtime/default/lib/ld-linux-aarch64.so.1 -> /lib/ld-linux-aarch64.so.1

The arm builds are different to the x86_64 build no matter the distro.

x86_64 Ubuntu image was like this:

squashfs-root/runtime/compat/lib64/ld-linux-x86-64.so.2 -> ../lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
squashfs-root/runtime/compat/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
squashfs-root/runtime/default/lib64/ld-linux-x86-64.so.2 -> /lib64/ld-linux-x86-64.so.2

Notice, the x86_64 image unlike the arm ones has the actual library file (not symlinks) in the runtime part of the tree.

The Ubuntu ld.so.conf contents for x86_64:

cat etc/ld.so.conf.d/x86_64-linux-gnu.conf 
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

The Ubuntu ld.so.conf contents for aarch64

# Multiarch support
/usr/local/lib/aarch64-linux-gnu
/lib/aarch64-linux-gnu
/usr/lib/aarch64-linux-gnu

They are consistent between architectures.

The yaml build file for the aarch64 ubuntu build was changed as below:

37,46c33,36
<       # arm sources and key_url from
<       # https://ftp-master.debian.org/keys.html
<       - sourceline: 'deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware'
<         key_url: 'https://ftp-master.debian.org/keys/archive-key-12.asc'
<       - sourceline: 'deb http://deb.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware'
<         key_url: 'https://ftp-master.debian.org/keys/archive-key-12-security.asc'
<       - sourceline: 'deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware'
<         key_url: 'https://ftp-master.debian.org/keys/release-12.asc'
<       - sourceline: 'deb http://archive.raspberrypi.com/debian/ bookworm main'
<         key_url: 'http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x82B129927FA3303E'
---
>       - sourceline: 'deb http://ports.ubuntu.com/ubuntu-ports/ jammy main restricted universe multiverse'
>         key_url: 'http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x871920D1991BC93C'
>       - sourceline: 'deb http://ports.ubuntu.com/ubuntu-ports/ jammy-security main restricted universe multiverse'
>       - sourceline: 'deb http://ports.ubuntu.com/ubuntu-ports/ jammy-updates main restricted universe multiverse'

Hope this helps.

[damoclark]

Hi @perrito666

I've identified the issue.

The problem is where the flom binary expects the ld-linux-aarch64.so.1 dynamic link loader to be located.

On x86_64, the following shows the path to this file for the flom binary that is deployed by builder:

file flom
flom: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=65a8bf4017ef85d1665d037eb2e218ec2a6149ae, for GNU/Linux 3.2.0, with debug_info, not stripped

Note the path /lib64/ld-linux-x86-64.so.2

In the AppDir structure, the file /lib64/ld-linux-x86-64.so.2 exists under squashfs-root/runtime/compat as squashfs-root/runtime/compat/lib64/ld-linux-x86-64.so.2

Looking at the aarch64 flom binary:

file flom
flom: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter lib/ld-linux-aarch64.so.1, BuildID[sha1]=8f9b91850a162185acbab2be5c65239f6f1aca1e, for GNU/Linux 3.7.0, with debug_info, not stripped

The file lib/ld-linux-aarch64.so.1 does not exist under squashfs-root/runtime/compat/lib directory at all. All libraries are under a subdirectory there called aarch64-linux-gnu but also ld-linux-aarch64.so.1 is not one of them. The ld-linux-aarch64.so.1 file should be located as squashfs-root/runtime/compat/lib/ld-linux-aarch64.so.1 just as the file exists at squashfs-root/runtime/compat/lib64/ld-linux-x86-64.so.2 for the x86_64 platform.

By symlinking a copy of the ld-linux-aarch64.so.1 file directly under lib/ directory, it fixes the problem. It's almost like that step was omitted by the builder:

cd squashfs-root/runtime/compat/lib
ln -s ../../default/lib/ld-linux-aarch64.so.1

I can now run the extracted appimage fine:

cd squashfs-root
./AppRun --version
FLoM: Free Lock Manager
Copyright (c) 2013-2024, Christian Ferrari; all rights reserved.
License: GPL (GNU Public License) version 2
Package name: flom; package version: 1.7.1; release date: 2024-01-01
TLS supported protocol(s): All TLS protocols
Access https://github.com/tiian/flom for project community activities
Documentation is available at http://www.tiian.org/flom/

[perrito666]

K ill try to fix this by ear since i do not have an aarch64 at hand :p ill pr and ask you to test it?

[perrito666]

Ok this seems yo go back a long time i see 2022 reports of related issue. I suspect LD_LIBRARY_PATH should fix it

[damoclark]

I've done a bit of tracking back too.

#289 includes the missing files for both aarch64 and armhf that is causing this problem.

So I think the problem may have already been fixed, but there hasn't been a release in such a long time, and that fix is not included.

Maybe a new release is all that is in order.

D

[perrito666]

Indeed that seems to fix several bugs that report on the same. We no longer use this project but it would be nice to get a release with up to date code.

[perrito666]

@azubieta Am I right to assume you are the person to ping about a release?

[azubieta]

@perrito666 I'm the one, but the kid is not my child 😄

I'll schedule a release for this weekend, thanks for contributing :)

[perrito666]

This seems our current status :p (hope i am not the only one old enough for the joke)

[damoclark]

@perrito666 haven't seen that movie in a long time. But it seems I'm older as my immediate thought was:

Thanks Horacio and Alex for playing guardian :)

D.

[damoclark]

@perrito666 I'm the one, but the kid is not my child 😄

I'll schedule a release for this weekend, thanks for contributing :)

Hi @perrito666

I did some work and issued a PR to fix a few issues with generating a new AppImage release for appimage-builder. See #345 for details of the fixes. If you merge this PR, you should be able to generate a new AppImage release file without too much trouble.

Damo.

[perrito666]

@damoclark i doubt i can merge anything i am not a maintainer of this project. I only have a couple of commits in for a few bugs i hit while using it in my company. 🤷 sorry

[damoclark]

@damoclark i doubt i can merge anything i am not a maintainer of this project. I only have a couple of commits in for a few bugs i hit while using it in my company. 🤷 sorry

No worries @perrito666, I understand.

@azubieta the TL;DR is that there are a number of important fixes in main that haven't made their way to a release version (and an updated AppImage release file). Wondering if you could review #346 I submitted, and if all is good, merge into main and generate a new release. It will reduce people submitting issues that have already been fixed (such as this one #304).

I attempted to bootstrap build an AppImage from main, but was thwarted by some minor issues which I've submitted PR #346 to address. Mostly updates to the recipes (notably the appimagebuilder recipe), and updating the build platform for appimage-builder from Ubuntu 20.04 to 22.04. Would you mind reviewing my PR, make any appropriate fixes/improvements and merge? And from that create a new release?

Many thanks.

Damo.