go-appimage treats executables as libraries to set RPATH

[brunvonlope]

Running objdump -c on binaries from an .appimage produced by go-appimage reveals that the tool uses executables paths as suitables to be appended on RPATH, not only the paths of libraries.

As far I know, it is not common dynamically linkining to executables on Linux. That was a thing on very early versions of Windows but not anymore. This seems a error.

@Samueru-sama probably can share some words too

[Samueru-sama]

Yeah that isn't right and quite a problem for gimp since there is a directory for each plugin.

[probonopd]

The intended behavior is that only directories containing libraries should be added to RPATH.

func patchRpathsInElf(appdir helpers.AppDir, libraryLocationsInAppDir []string, path string) does the patching.

Apparently somewhere directories not actually containing .so files get added to libraryLocationsInAppDir, can you spot where?

[brunvonlope]

can you spot where?

@probonopd GIMP plug-ins are stored in lib path, this way:

AppDir/usr/lib/arch_triplet/gimp/3.0/plug-ins/plugin_name/plugin_name_executable

The intended behavior is that only directories containing libraries should be added to RPATH

What is a library for go_appimage? go-appimage seems to consider a library whatever ELF files that it found recursively on lib path, independently of the *so extension, creating this monstruosity:

[probonopd]

Yes, I guess we need to change that by checking whether a path contains at least one file with the extension .so optionally followed by any combination of dots and numbers before adding to libraryLocationsInAppDir.

[probonopd]

Does the build in #316 improve the situation?