Could not start patchelf, version `Qt_5.8' not found errors

[ubruhin]

Hi,

my Qt application LibrePCB requires to load some resource files at runtime (for example some license templates) which I consider to store in the directory ../share/librepcb/ relative to the executable. So If the executable is installed to /usr/bin/librepcb, it searches for resources at /usr/share/librepcb/.

To make this working inside AppImages, the executable needs to be located in a subdirectory (e.g. ./bin/) of the AppDir. Is there a way to do this with linuxdeployqt? As far as I can see, linuxdeployqt assumes that the application executable is located in the root of the AppDir...

[probonopd]

Hi @ubruhin. Thanks for your interest in linuydeployqt. Loading resources from locations relative to the main binary like you describe is a very good approach.

In fact, I started to work on a FHS-like mode where linuxdeployqt should check whether the main executable is in a FHS-like structure, i.e., whether its parent directory is called bin/ and (possibly) whether there is a ../lib/ directory. If so, it should use those directories to deploy to rather than putting lib/ next to itself (which would result in a rather nonstandard bin/lib/).

My initial code on this can be found in the feature/fhs branch but it seems i am running into this issue which I have been unable to resolve so far. Maybe you can find the culprit?

[ubruhin]

In fact, I started to work on a FHS-like mode

Great to hear!

Maybe you can find the culprit?

I have just looked into your source code, but unfortunately it's kind of hard to understand because it looks not very well structured (only 2 source files, no object oriented design, ...) 😉 Maybe I could do some refactoring first, if you agree with that?

[probonopd]

To be honest, I find the current structure hard to work with too, but I had modeled linuxdeployqt 1:1 after the already-existing macdeployqt which is part of Qt, in order to

• benefit from the work that was already there in macdeployqt
• increase chances to have it included in Qt one day, too

I'm all for refactoring @ubruhin if the flow is easier to understand afterwards, and if we still have a chance to get it into Qt. Also look at macdeployqt and windeployqt.

[ubruhin]

I had modeled linuxdeployqt 1:1 after the already-existing macdeployqt

Alright, that's probably a good reason to keep the current structure.

increase chances to have it included in Qt one day, too

That would be amazing! 😃 But wouldn't it be easier to bring linuxdeployqt into Qt if it doesn't know AppImageKit ( -> get rid of this dependency, because AppImageKit has nothing to do with Qt)? IMHO it would be no problem if developers need to execute two steps for creating AppImages (first linuxdeployqt, then AppImageKit).

Also look at macdeployqt and windeployqt.

I will take a look on them the next few days.

[probonopd]

AppImageKit is not a dependency. It's a "works-well-with" relationship. It's not being used by default. I like to keep it.

[larpon]

I don't find the code base appealing either. IMHO it's starting to look more like a spaghetti-hack of macdeployqt than a proper well written Qt deploy tool for linux.

benefit from the work that was already there in macdeployqt

MacOS is not Linux - Linux does things a little differently as you might know now.

increase chances to have it included in Qt one day, too

Any well-written (Qt-based) tool that solves a problem will have a chance.
Whatever the tool may be it'll have to go through code review - so the code base will meet whatever standards the Qt community think it needs.

Don't get me wrong here - I think this project rocks and I wish it all the best. I also think, though, that linuxdeployqt actually got higher chances of being included (and attract more developers) if you refactor/rewrite from scratch - instead of shoehorning and patching up macdeployqt. Different OS = different needs, different ways of doing things - and maybe most importantly - different programmers with different skillsets.

Start by getting the library dependency resolving rock-solid and take it from there.

Maybe even keep some layers Qt-independant or, even better, make them plugin-based so you can add a plugin that handle Qt's oddities. This way you'd have a tool flexible enough to build AppImages for many Linux binaries. And keep the output generators as plugins as well - that way you'd have an AppImage output plugin that generates AppImages, one that generates a .json list of dependencies, one that pack everything into a zip archive, one that wrap a tool to make .deb packages - you get the idea.

If a tool like that is written in a portable (Qt based) way you'll maybe even end up having all the *deployqt's replaced by plugins :)

• one can dream :)
• I might be shooting way, way, over the bar here - but I still think a refactor wouldn't hurt the project

[probonopd]

This is way over my head (this being my first Qt project ever), but I'd welcome it happening.

[probonopd]

FHS-like mode is now implemented and (hopefully) working, please try https://github.com/probonopd/linuxdeployqt/releases/tag/continuous. Turns out that strip has a bug that cripples binaries on which patchelf was previously run (NixOS/patchelf#10). Therefore, I am now checking whether a binary has a rpath starting with $ (indicating that we already ran patchelf on it), and not run strip in that case. c643d6a

Let me know if this solves it for you.

[ubruhin]

Now I get other errors:

• With Qt5.2 from Ubuntu Repos: https://travis-ci.org/LibrePCB/LibrePCB/jobs/201952944#L2495
• With Qt5.7 from beineri PPA: https://travis-ci.org/LibrePCB/LibrePCB/jobs/201952945#L2191

[probonopd]

Sorry for the trouble you are having @ubruhin

With Qt5.2 from Ubuntu Repos: https://travis-ci.org/LibrePCB/LibrePCB/jobs/201952944#L2495

ERROR: Could not start patchelf.
ERROR: Make sure it is installed on your $PATH, e.g., in /usr/local/bin.
ERROR: You can get it from https://nixos.org/patchelf.html.

With Qt5.7 from beineri PPA: https://travis-ci.org/LibrePCB/LibrePCB/jobs/201952945#L2191

linuxdeployqt: /opt/qt57/lib/libQt5Core.so.5: version `Qt_5.8' not found (required by linuxdeployqt)

Are you sure you have the correct Qt on your $PATH as pointed out in README.md?

I need to investigate what is going on. Any help appreciated.

[ubruhin]

Sorry for the trouble you are having @ubruhin

No problem ;)

Are you sure you have the correct Qt on your $PATH as pointed out in README.md?

Yes, this is be done with sourcing the file /opt/qt57/bin/qt57-env.sh. If that wouldn't work, I couldn't build my own application too.

I will try to debug this on my own machine...

[probonopd]

@ubruhin please retest, I think the

ERROR: Could not start patchelf.
ERROR: Make sure it is installed on your $PATH, e.g., in /usr/local/bin.
ERROR: You can get it from https://nixos.org/patchelf.html.

should be solved by your PR, b3b9ec7

[ubruhin]

Yes, Could not start patchelf is fixed and the AppImage gets created. But when executing, there's the same problem as described in #75.

The version Qt_5.8 not found is still there when using Qt5.7...

[probonopd]

The version Qt_5.8 not found is still there when using Qt5.7...

Where are you getting your linuxdeployqt from? I have compiled linuxdeployqt with Qt 5.8 and it needs that to run. The linuxdepoyqt.AppImage should contain that bundled...

[ubruhin]

Where are you getting your linuxdeployqt from?

I use the official linuxdeployqt-continuous-x86_64.AppImage: https://github.com/LibrePCB/LibrePCB/blob/deploy_appimage_sandbox/dev/travis/install.sh#L18

[probonopd]

That is very strange. Can you please check with

wget -c "https://github.com/probonopd/linuxdeployqt/releases/download/continuous/linuxdeployqt-continuous-x86_64.AppImage"
chmod a+x linuxdeployqt-continuous-x86_64.AppImage 
./linuxdeployqt-continuous-x86_64.AppImage --appimage-extract
ldd ./squashfs-root/usr/bin/linuxdeployqt | grep libQt

It should load libQt5Core.so.5 from within the AppImage, and for me it seems to do that:

me@host:~$ ldd ./squashfs-root/usr/bin/linuxdeployqt | grep libQt
	libQt5Core.so.5 => /home/me/./squashfs-root/usr/bin/../lib/libQt5Core.so.5 (0x00007ff08df2e000)

[ubruhin]

With Qt5.2 from the Ubuntu repository it looks good to me:

libQt5Core.so.5 => /home/travis/build/LibrePCB/LibrePCB/./squashfs-root/usr/bin/../lib/libQt5Core.so.5 (0x00007f2a66679000)

But with Qt5.7 from the beineri PPA, it looks bad:

libQt5Core.so.5 => /opt/qt57/lib/libQt5Core.so.5 (0x00007fb265a41000)

Maybe this is somehow caused by sourcing the file /opt/qt57/bin/qt57-env.sh, but what happens exactly?

[probonopd]

Please try to unset the environment variables set by /opt/qt57/bin/qt57-env.sh prior to running linuxdeployqt, with the only exception of $PATH that still should contain qmake from /opt/qt57.

[ubruhin]

That works!

I just saw that /opt/qt57/bin/qt57-env.sh contains following lines:

if [[ $(uname -m) == "x86_64" ]]; then
  export LD_LIBRARY_PATH=$QT_BASE_DIR/lib/x86_64-linux-gnu:$QT_BASE_DIR/lib:$LD_LIBRARY_PATH
else
  export LD_LIBRARY_PATH=$QT_BASE_DIR/lib/i386-linux-gnu:$QT_BASE_DIR/lib:$LD_LIBRARY_PATH
fi

I guess this is the problem. As the directories contained in LD_LIBRARY_PATH have highest priority when searching for libraries, libraries contained in the AppImage may be overridden.

But how to deal with that problem? ;)

[probonopd]

I think the clue may be in http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/

Some experiments and reading the glibc source code (check _dl_map_object in elf/dl-load.c) indicate that this is the library search order:

Unless loading object has RUNPATH:
    RPATH of the loading object,
        then the RPATH of its loader (unless it has a RUNPATH), ...,
        until the end of the chain, which is either the executable
        or an object loaded by dlopen
    Unless executable has RUNPATH:
        RPATH of the executable
LD_LIBRARY_PATH
RUNPATH of the loading object
ld.so.cache
default dirs