Payload application must run no matter what

[probonopd]

We need to find a solution that would make the payload application run no matter what issues desktop-integration might be running into.

In the bash version of the desktop integration script this is ensured.

cc @darealshinji

[TheAssassin]

In the bash version of the desktop integration script this is ensured.

Not really. It's still for example relying on bash being available, and if it wasn't, it won't run either.

This could only be solved reliably by adding code to the runtime. If payloadapp.wrapper exists, run that, if it fails, run payloadapp, otherwise just run payloadapp, or something like that.

[probonopd]

Couldn't we do the same using a "secondary runtime" executable?

[TheAssassin]

A binary that checks whether a binary runs? Now it's getting a bit odd.

I'd rather write a test script, checking whether the dependencies are nothing but what's listed in the exclude list (top level of course, you can't control what's being pulled in by system libs, but you can rely on those dependencies to be there). Maybe we should further define a "test system" which has no dependencies installed (Docker container preferably), and run it there once to see whether it works.

[TheAssassin]

The goal is to make this binary robust, not to add more and more binaries and scripts. Those "workarounds" are not an option to me, to be honest. (And I'd also like to avoid shipping this as an AppImage, too.)

[TheAssassin]

So, libraries which the app depends on, which are not in the exclude list:

• libcairo.so.2
• libXft.so.2

FLTK pulls in libcairo, but won't use it, so I will look into getting rid of it. However, libXft is required for configuring the font using libDE, and we probably don't want to remove that.

To solve the latter issue, we have two options: Either bundle it and make the desktop integration an AppImage, or inspect the library and consider adding it to the exclude list. @probonopd, did you ever meet libXft, and can tell us something about it? It's not in the exclude list at the moment, so I'll be looking into the Git history.

[probonopd]

libXft

I have never investigated it so far.

[TheAssassin]

I'll try to use the testappimage script to check whether the library is available in all relevant distros.

[darealshinji]

As a side note, libXft is also required to make the fonts in FLTK look nice, otherwise they look really ugly.

[TheAssassin]

@darealshinji thanks, that's what I wanted to point to, too.

[probonopd]

How commonly availlable is libXft "everywhere", and in which versions?

[darealshinji]

A typical common and stable X library I guess:
https://packages.ubuntu.com/search?keywords=libXft&searchon=names&suite=all&section=all
https://packages.debian.org/search?keywords=libXft&searchon=names&suite=all&section=all
https://rpmfind.net/linux/rpm2html/search.php?query=libXft.so.2

It's libXft.so.2 everywhere.

[TheAssassin]

Yeah, it looks like it's available in most systems anyway. I wouldn't worry too much about it.

[probonopd]

OK

[TheAssassin]

At the moment I'm trying to convince FLTK to not link to libcairo.

[darealshinji]

Shouldn't there be an option to disable cairo in cmake?

[TheAssassin]

Yes, and I've tried it, and it also seems like it respects it (set(OPTION_CAIRO OFF), also said to be the default). However, lddtree shows it's still linking to it, and it's a top-level dependency, i.e., not referenced by a library but the main binary.

I'll push the changes, could you have a look, please?

[darealshinji]

Indeed, that's what I get from readelf:

 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libXrender.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libXft.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libfontconfig.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpng12.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgio-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgobject-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgmodule-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgthread-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

If -DOPTION_CAIRO=OFF doesn't work, you could 1) try to remove all the glib/cairo devel packages before building or b) link with -Wl,--as-needed because maybe they're accidentally dragged in through pkg-config.
Btw libpng should be linked statically as well.

[TheAssassin]

libpng is linked statically, at least for FLTK. However, libXft references it in again, see the lddtree output:

dialog => src/dialog (interpreter => /lib64/ld-linux-x86-64.so.2)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
        ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
            libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
            libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
    libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
            libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
        libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
    libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
    libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
        libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
    libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
        libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6
    libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2
        libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
        libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
        libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

One can't fix that, so I guess it won't have any negative effects.

[darealshinji]

No, it's references directly by the dialog binary files from the release section.
You must check the NEEDED entries with readelf:

$ LANG=C readelf -d dialog-x86_64 | grep png
 0x0000000000000001 (NEEDED)             Shared library: [libpng12.so.0]
$ LANG=C readelf -d dialog-i686 | grep png
 0x00000001 (NEEDED)                     Shared library: [libpng12.so.0]

I guess you were checking a file that you built on your own PC?

[TheAssassin]

You're right, I didn't expect a difference in that, though. lddtree dialog-x86_64 confirms that libpng.so.12 is directly referenced. I'd really like to know why this is happening, though...