On 8/23/22 05:00, Thiago Macieira wrote:
Please have them run with QT_DEBUG_PLUGINS=1 and send you the output. There'll
be a line there saying that the plugin failed to load because something
happened. It's probably a missing system library.
Have your users install that if it is the case.
If you are really lucky, Thiago's advice above will work for you. I will
assume you don't tend to lead a charmed life.
Distributing binaries via tar or zip is always a bad idea because one
cannot control the dependencies. Look into Flatpak. The KDE project has
a base with Qt sans WebEngine stuff already.
To help with the more immediate problem, have one of the users open a
The problem is lower in this food chain, but you want to see where the
main executable is loading things from. Output will look like this:
libCsSql1.7.so => /usr/local/cs_lib/lib/libCsSql1.7.so
libCsScintilla.so.5 => /usr/local/cs_lib/lib/libCsScintilla.so.5
liblexilla.so => /usr/local/lib/Lexilla/liblexilla.so
libCsGui1.7.so => /usr/local/cs_lib/lib/libCsGui1.7.so
libCsCore1.7.so => /usr/local/cs_lib/lib/libCsCore1.7.so
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.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 (0x00007fc2ff764000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc2ff75e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc2ff5ec000)
libOpenGL.so.0 => /lib/x86_64-linux-gnu/libOpenGL.so.0
libjpeg.so.8 => /lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fc2ff539000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc2ff51d000)
libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0
If Thiago's answer is correct, one of those lines will end with => and
nothing or null (I forget which) That will be your missing library. It
could also be further down. Repeat as-needed for each of the libraries
on the right hand side of the output.
Missing is easy to solve.
**The problem could also be they installed something that has a newer,
You need to compare the ldd output with what you have on your working
system . . . assuming it wasn't just a missing library.
Many (possibly all) RPM based distros have blocked the RPATH trick.
Ubuntu and the YABUs have not, but you are supposed to now use $ORIGIN
on Linux anyway. MAC has @rpath and several others. Nice article here.
If you just want to see a CMakeLists.txt that actually uses it for
Linux, search for $ORIGIN in this one.
This goes in the first CMakeLists.txt, not the second.
Assuming you won't run into any licensing issues, you need to bundle all
of the needed libraries, not just the Qt libraries, with your executable
and use $ORIGIN line to control where your executable looks first. If
you weren't previously setting $ORIGIN, you were just getting lucky.
If you are looking to get a leg up on this problem and "traditional"
build-reddiamond-deb.sh runs on Ubuntu to make Debian package
build-reddiamond-rpm.sh runs on Fedora to make RPM package
Both start with a build tree where the binary and all supporting files
exist. The Debian one is under 200 lines and the RPM just over 100. With
"traditional" packaging you can control the dependencies.
Yes, our AppImage fans from the prevous linuxdeployqt message thread can
also rightly speak up here.
If your app broke because of something newer being installed, you are
going to be on a treadmill of chasing system dependencies that keep
Roland Hughes, President
Interest mailing list