[Interest] Deploying 5.15.2 on Ubuntu 20.04, (Qt5OpenGL.so)

[Roland Hughes]

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.

Michael,

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 
terminal

cd directory-with-broken-app

ldd my-broken-app

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:

roland at roland-HP-EliteDesk-800-G2-SFF:~/sf_projects/reddiamond_debug$ 
ldd reddiamond
     linux-vdso.so.1 (0x00007fff8d582000)
     libCsSql1.7.so => /usr/local/cs_lib/lib/libCsSql1.7.so 
(0x00007fc303c7b000)
     libCsScintilla.so.5 => /usr/local/cs_lib/lib/libCsScintilla.so.5 
(0x00007fc3039ba000)
     liblexilla.so => /usr/local/lib/Lexilla/liblexilla.so 
(0x00007fc3038ee000)
     libCsGui1.7.so => /usr/local/cs_lib/lib/libCsGui1.7.so 
(0x00007fc300486000)
     libCsCore1.7.so => /usr/local/cs_lib/lib/libCsCore1.7.so 
(0x00007fc2ffb55000)
     libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x00007fc2ff973000)
     libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x00007fc2ff956000)
     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 
(0x00007fc2ff73b000)
     libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc2ff5ec000)
     /lib64/ld-linux-x86-64.so.2 (0x00007fc30445f000)
     libOpenGL.so.0 => /lib/x86_64-linux-gnu/libOpenGL.so.0 
(0x00007fc2ff5be000)
     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 
(0x00007fc2ff465000)


cd directory-with-Qt5OpenGL.so

ldd Qt5OpenGL.so

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, 
incompatible version.**

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.

https://dev.my-gate.net/2021/08/04/understanding-rpath-with-cmake/

If you just want to see a CMakeLists.txt that actually uses it for 
Linux, search for $ORIGIN in this one.

https://sourceforge.net/p/reddiamond/code/ci/master/tree/CMakeLists.txt

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" 
packaging.

https://sourceforge.net/p/reddiamond/code/ci/master/tree/

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.

https://appimage.org/

https://askubuntu.com/questions/1386538/steps-to-create-an-appimage


If your app broke because of something newer being installed, you are 
going to be on a treadmill of chasing system dependencies that keep 
becoming incompatible.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog