[SOLVED] [Qt, image-formats, plugins] I do not understand this framework anymore.

Michael Uplawski · 04-17-2018, 09:23 AM

Here is my problem:

How do I publicize the location of a system-wide plugins-directory upon installation of my own application?

And add

... if the directory is anyway a system-wide setting, relative to $QTDIR (the installation-path of the Qt-framework in use)

...

And why should I need this in the first place?

Observation
An application which reads diverse image-formats since 2004, does so in the development environment, but no longer after installation of the only executable in /usr/bin.

One conclusion after some research
The image-formats are handled by plugin libraries which are found in the plugins directory, relative to $QTDIR.

AFAIS, you can set the paths to diverse plugins and plugin-directories programmatically... but why should I? What do I know about the installation-paths on any other computer?

Chances are, my English failed me again, when I was reading the docs. Can you do this in pigeon-english for me, PSE?

TY.

PS.: The application in question is in my blog.
PPS.: DARN.

norobro · 04-17-2018, 12:30 PM

I'm probably missing something, I usually do.

I tested your app by compiling it against Qt-5.7.1 and, since I'm running KDE, against the system Qt libs.

Code:

~/temp/upsslideshow$ qmake -v
QMake version 3.0
Using Qt version 5.7.1 in /data/Qt-5.7.1/5.7/gcc_64/lib

~/temp/upsslideshow$ ldd upsslideshow | grep Qt5
        libQt5Widgets.so.5 => /data/Qt-5.7.1/5.7/gcc_64/lib/libQt5Widgets.so.5 (0x00007fc99a092000)
        libQt5Gui.so.5 => /data/Qt-5.7.1/5.7/gcc_64/lib/libQt5Gui.so.5 (0x00007fc999906000)
        libQt5Core.so.5 => /data/Qt-5.7.1/5.7/gcc_64/lib/libQt5Core.so.5 (0x00007fc9991e8000)

~/temp/upsslideshow_system$ /usr/lib/x86_64-linux-gnu/qt5/bin/qmake -v
QMake version 3.1
Using Qt version 5.10.1 in /usr/lib/x86_64-linux-gnu

~/temp/upsslideshow_system$ ldd upsslideshow | grep Qt5
        libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007fe7d0fe8000)
        libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007fe7d084e000)
        libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007fe7d014f000)

After installation, it seems to me both versions work fine.

BTW, nice program.

John VV · 04-17-2018, 01:08 PM

is this QT4 or 5 ?

in 5 there are changes to the core qt system file locations

and some api changes

Michael Uplawski · 04-17-2018, 01:51 PM

Quote:

Originally Posted by John VV

is this QT4 or 5 ?

in 5 there are changes to the core qt system file locations

and some api changes

Thank you John. I am aware of the API changes and they do not frighten me. In fact I had to modify the code at different spots to make it run with Qt5..; now it looks like have not bungled this part.

The “qt system file locations” may have changed, but why should I have to bother? This may be a new obligation, introduced with Qt5 and it appears to be exactly the source of my troubles. More precisely these “plugins” which come from nowhere and suddenly impose that I care for them.

Michael Uplawski · 04-17-2018, 01:54 PM

Quote:

Originally Posted by norobro

After installation, it seems to me both versions work fine.

I should be nervous, reading that the program may run on one system, maybe many systems, but still fails on my own.

But with respect to all the mess that I have created in my configurations in the past, your observation may just point at yet another one of my own destructive interventions.., that I have lost track of in the meantime.

Thank you norobro. I shall scrutinize my development environment for the glitch.

STOP and Edit: Does the program read and display Tiff-files, PNG, BMP and the like or is it JPEG only?

Michael Uplawski · 04-17-2018, 03:14 PM

Additional Info:

I added a call to QLibraryInfo like this:

Code:

qDebug() << " plugins should be in " << QLibraryInfo::location(QLibraryInfo::PluginsPath);

Run from QTCreator, the output is as expected:

Quote:

plugins should be in "/opt/Qt-sdk/5.10.1/gcc_64/plugins"

After installation, the program reports:

Quote:

plugins should be in "/usr/plugins"

I try to find possible reasons for the choice of the nonexistent directory /usr/plugins. For example, the project-file has an entry

Code:

target.path = /usr/bin

INSTALLS += target

which should not do strange things. The installation of the executable in /usr/bin is normal.

$QTDIR is set but obviously does not have the slightest influence.

norobro · 04-17-2018, 04:34 PM

Quote:

Originally Posted by Michael Uplawski

Does the program read and display Tiff-files, PNG, BMP and the like or is it JPEG only?

Yep. It cycles through these files:

Code:

~/temp$ ls -ln slides/
total 72
-rw-r--r-- 1 1000 1000 49220 Jan 19  2005 cube.bmp
-rw-r--r-- 1 1000 1000  6968 Jul  3  2011 LinuxLogo.jpg
-rw-r--r-- 1 1000 1000  4244 Dec  7  2011 Pause.tiff
-rw-r--r-- 1 1000 1000   324 Mar 14 10:54 stroke.png

After compiling against the sdk and running make install, the qDebug() statement outputs:

Code:

~$ upsslideshow
 plugins should be in  "/data/Qt-5.7.1/5.7/gcc_64/plugins"

Michael Uplawski · 04-18-2018, 01:46 AM

I am doomed.
Avoid western-Europe for a while.

norobro · 04-18-2018, 09:28 AM

I browsed the docs a bit and noticed "qmake -query": https://doc.qt.io/qt-5/qmake-environment-reference.html

Just a shot in the dark, but do you have relative paths set for any of the properties?

Code:

$ qmake -query
TARGET:application
QT_SYSROOT:
QT_INSTALL_PREFIX:/data/Qt-5.7.1/5.7/gcc_64
QT_INSTALL_ARCHDATA:/data/Qt-5.7.1/5.7/gcc_64
QT_INSTALL_DATA:/data/Qt-5.7.1/5.7/gcc_64
QT_INSTALL_DOCS:/data/Qt-5.7.1/5.7/gcc_64/doc
QT_INSTALL_HEADERS:/data/Qt-5.7.1/5.7/gcc_64/include
QT_INSTALL_LIBS:/data/Qt-5.7.1/5.7/gcc_64/lib
QT_INSTALL_LIBEXECS:/data/Qt-5.7.1/5.7/gcc_64/libexec
QT_INSTALL_BINS:/data/Qt-5.7.1/5.7/gcc_64/bin
QT_INSTALL_TESTS:/data/Qt-5.7.1/5.7/gcc_64/tests
QT_INSTALL_PLUGINS:/data/Qt-5.7.1/5.7/gcc_64/plugins
QT_INSTALL_IMPORTS:/data/Qt-5.7.1/5.7/gcc_64/imports
QT_INSTALL_QML:/data/Qt-5.7.1/5.7/gcc_64/qml
QT_INSTALL_TRANSLATIONS:/data/Qt-5.7.1/5.7/gcc_64/translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES:/data/Qt-5.7.1/5.7/gcc_64/examples
QT_INSTALL_DEMOS:/data/Qt-5.7.1/5.7/gcc_64/examples
QT_HOST_PREFIX:/data/Qt-5.7.1/5.7/gcc_64
QT_HOST_DATA:/data/Qt-5.7.1/5.7/gcc_64
QT_HOST_BINS:/data/Qt-5.7.1/5.7/gcc_64/bin
QT_HOST_LIBS:/data/Qt-5.7.1/5.7/gcc_64/lib
QMAKE_SPEC:linux-g++
QMAKE_XSPEC:linux-g++
QMAKE_VERSION:3.0
QT_VERSION:5.7.1

Michael Uplawski · 04-19-2018, 02:57 AM

@norobro: You are officially cool.

All QT_INSTALL variables are pointing at /usr, while Qt is installed in /opt.
Without knowing if it can solve anything, I will reinstall the whole framework, as this confusion must originate in the way that Qt had been installed.

Grepping through the divers *.conf files for qmake does not help me find the error. We'll see.

Michael Uplawski · 04-19-2018, 04:08 AM

And YEP! That “solved it”.
While trying to understand a problem is part of the solution-finding and understanding is part of the solution, this time, again, the only thing I learned is: Ask Folks Who Know Stuff!

I still have to set the LD_LIBRARY_PATH to the lib-subdirectory of the installed SDK-version, but the plugins appear to be found and qmake -query knows again, what it is doing.

Michael Uplawski · 04-28-2018, 05:41 AM

This only solved it for some time.

Now I have capitulated and created the symbolic link to /usr/plugins, that qmake insists on.