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

2022-08-23 Thread Michael Jackson

On 8/22/22, 10:24 AM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Monday, 22 August 2022 09:11:29 -03 Michael Jackson wrote:
> For our open source program we create self-contained .tar.gz archives for
> users to download. Currently we use Qt5.15.2 for those archives. After
> packaging I run a sanity check on my Ubuntu 20.04 fully patched system and
> the program will launch just fine. It is a GUI based program. Last week 2
> users reported that when the launch the program on their Ubuntu 20.04
> systems they get an error when one of our Plugins loads (we use Qt's 
plugin
> infrastructure to load) that basically says the plugin cannot load because
> Qt5OpenGL.so could not be loaded. That library is in the proper location
> (alongside all of the other libraries in the install). I'm not a linux 
guy
> and Googling didn't really turn anything up that was helpful. We dropped
> back to an older version of our program where I built against Qt5.9 and
> those binaries worked just fine. I'm looking for advice on what might be
> the issue? OpenGL drivers (The user's machine was using a Mesa install
> running on an Intel HD hardware). I think we actually build on Ubuntu
> 18.04 but we build against the Qt5.15 binaries from Qt.io instead of 
system
> installed Qt binaries. Maybe that is the issue? Advice is appreciated.

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


So we tracked down the issue to when we are creating the installer (through 
cmake) and the RPATHS are all getting adjusted for the dependent libraries, one 
library does NOT get adjusted and that library still references a system 
installed Qt5. I will have to go back through the install codes to figure out 
why that is not occurring.

Thanks for all the hints, it helped get us to the answer.

--
Mike Jackson


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


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

2022-08-23 Thread Roland Hughes via Interest


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@roland-HP-EliteDesk-800-G2-SFF:~/sf_projects/reddiamond_debug$ 
ldd reddiamond

    linux-vdso.so.1 (0x7fff8d582000)
    libCsSql1.7.so => /usr/local/cs_lib/lib/libCsSql1.7.so 
(0x7fc303c7b000)
    libCsScintilla.so.5 => /usr/local/cs_lib/lib/libCsScintilla.so.5 
(0x7fc3039ba000)
    liblexilla.so => /usr/local/lib/Lexilla/liblexilla.so 
(0x7fc3038ee000)
    libCsGui1.7.so => /usr/local/cs_lib/lib/libCsGui1.7.so 
(0x7fc300486000)
    libCsCore1.7.so => /usr/local/cs_lib/lib/libCsCore1.7.so 
(0x7fc2ffb55000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fc2ff973000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fc2ff956000)

    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc2ff764000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc2ff75e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fc2ff73b000)

    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fc2ff5ec000)
    /lib64/ld-linux-x86-64.so.2 (0x7fc30445f000)
    libOpenGL.so.0 => /lib/x86_64-linux-gnu/libOpenGL.so.0 
(0x7fc2ff5be000)

    libjpeg.so.8 => /lib/x86_64-linux-gnu/libjpeg.so.8 (0x7fc2ff539000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fc2ff51d000)
    libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 
(0x7fc2ff465000)



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

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest