Removing -lGL from the default linker options in qt creator
-
I guess it is embedded somewhere in QtGui .pri or .prl files, you'll have to search there. Or maybe it's in mkspecs but I doubt it.
You can try the brute force approach:
LIBS -=-lGLqtcreator itself (which is obviously a GUI app) does not require gl to be installed (i have "minimal install" xubuntu-21.04)
Weird! That should not be possible in Qt 5. Interesting!
-
Hi,
The gui and multimedia modules both use OpenGL hence the requirement on that library. You will have to fiddle with your Qt installation which is not recommended.
Qt Creator uses the xcb backend by default and you likely have the OpenGL libraries installed on your system just not the corresponding development package(s).
-
I guess it is embedded somewhere in QtGui .pri or .prl files, you'll have to search there. Or maybe it's in mkspecs but I doubt it.
You can try the brute force approach:
LIBS -=-lGLqtcreator itself (which is obviously a GUI app) does not require gl to be installed (i have "minimal install" xubuntu-21.04)
Weird! That should not be possible in Qt 5. Interesting!
-
Hi,
The gui and multimedia modules both use OpenGL hence the requirement on that library. You will have to fiddle with your Qt installation which is not recommended.
Qt Creator uses the xcb backend by default and you likely have the OpenGL libraries installed on your system just not the corresponding development package(s).
@SGaist hmmm... i'm using only QCamera for now, so i only need only multimediawidgets to compile, but even so it links against gl. If gl is required by the app, then why does my app work even if i manually remove the -lGL. When i change the topmost source file (which is included in everything else) i foce the compiler to recompile everything, and the last step is to rebuild the app. The link command clearly shows no -lGL is used when linking, and no errors are reported and the app works.
the autogenerated CMake file contains:
LIBS = $(SUBLIBS) /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5MultimediaWidgets.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Multimedia.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Widgets.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Gui.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Network.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Core.so -lGL -lpthreadand i remove -lGL:
LIBS = $(SUBLIBS) /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5MultimediaWidgets.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Multimedia.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Widgets.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Gui.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Network.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Core.so -lpthread
then recompile (every file gets recompiled) and link:
clang++ -ccc-gcc-name g++ -Wl,-rpath,/home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib -Wl,-rpath-link,/home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib -o midicam_qt libagents.o libimage.o libucharvector.o libmidicam.o kalibrator.o keyboard.o testform1.o main.o testform2.o shell.o sigobject.o storage.o libfilecab.o global_defs.o libdebug.o udplocalhost.o libudplink.o tcpnet.o libutilz.o tests2.o tests1.o shellcontroller.o core.o midicam_defs.o module.o agmain.o mdcamera.o mdstabilizer.o mainwindow.o ezcam.o qrc_midicam_img.o moc_testform1.o moc_testform2.o moc_shellcontroller.o moc_mainwindow.o moc_ezcam.o /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5MultimediaWidgets.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Multimedia.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Widgets.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Gui.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Network.so /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5Core.so -lpthreadand no errors and the app runs just fine (the app is GUI, it even contains drawings)..
-
Run
lddon your executable and you'll see if OpenGL is used at runtime or not.Probably the linker is satisfied just by linking QtGui, which implicitly ink against OpenGL already.
-
yes, that's what happens:
libQt5OpenGL.so.5 => /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5OpenGL.so.5 (0x00007f795b2ba000) libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f795b232000) libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f7958d35000) libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f7958d01000)so probably sgaist is right about actually only needing to install the dev packages, but my question still remains (although admittedly with a twist): can i somehow get rid of the requirement to install the dev libs when i actually don't need them for my app?
-
yes, that's what happens:
libQt5OpenGL.so.5 => /home/gyll/Qt-5.15.2/5.15.2/gcc_64/lib/libQt5OpenGL.so.5 (0x00007f795b2ba000) libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f795b232000) libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f7958d35000) libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f7958d01000)so probably sgaist is right about actually only needing to install the dev packages, but my question still remains (although admittedly with a twist): can i somehow get rid of the requirement to install the dev libs when i actually don't need them for my app?
@gyll said in Removing -lGL from the default linker options in qt creator:
can i somehow get rid of the requirement to install the dev libs when i actually don't need them for my app?
You only need the dev libs on your dev machine - not on target system.
But, to answer your question: you can download the dev libs separately, extract them to some non-system directory and then modify the LD_LIBRARY_PATH in build environment so that linker will see the dev GL libs, but the app (later) won't.
-
@sierdzio okay, thanks, i'm not sure i want to do that because i will eventually run into version compatibility issues between the installed gl and the dev libs i'm downloading, but thanks again. all in all this ping-pong was informative for me, at least i now know why qt creator and my apps appeared to me to work w/o gl.
Thank you guys, both!
PS
actually what i'm using is a home-made "offline installer" of qt, i installed w/ the online installer, then installed the qtcreator-4.15.2 which is the least buggy (for me) at thim moment in time, then d/l the platformplugins and dependencies, upacked all of those in the qt libs dir in both the qt-5.15.2 and qtcreator etc etc etc, and i somehow managed to get a relatively stable environment hopefully for a couple of years. These guys at qt break ABIs when incrementing the minor version (despite their promise not to do so), they have all sorts of regressions in qtcreator that are driving me mad, the ubuntu repos pack whatever they feel like packing from qt at each release (in 21.04 i had to go through apt-get install qtcreator qtbase5-dev qtchooser qt5-qmake qtbase5-dev-tools), so i need a stable environment every time i have to upgrade the distro and it literally takes me weeks to get things working again. Everything in linux distros is suuuuuuch a mess, i guess i'll have to go back to windows or move away from qt, it's becoming increasingly messy w/ each release (and no longer providing offline installers doesn't help either...) -
@gyll said in Removing -lGL from the default linker options in qt creator:
because i will eventually run into version compatibility issues between the installed gl and the dev libs i'm downloading,
What do you mean by that ?
The OpenGL libraries are the from your system. The corresponding dev packages just add some more symlinks and headers. Why would that clash with additional libraries you may download ? -
@gyll said in Removing -lGL from the default linker options in qt creator:
because i will eventually run into version compatibility issues between the installed gl and the dev libs i'm downloading,
What do you mean by that ?
The OpenGL libraries are the from your system. The corresponding dev packages just add some more symlinks and headers. Why would that clash with additional libraries you may download ?@SGaist i mean, if i'm d/l the dev libs (w/ the corresponding headers and all) version so.r.n for future use, and then i'll be using the system gl release so.r.n+, i'm worried that the dv libs headers from so.r.n will no longer be compatible (read: accurately reflect) the newer system gl from so.r.n+. In this specific case where libGL are system libs they [most likely] follow the rule if "so.r.n+ is ABI-compatible with so.r.n", so in this specific this shouldn't be a problem, but seeing all the compatibility problems that occur with the various library versions in linux... i dunno... theoretically everything in linux should work w/o any library version problems, but with people removing and/or breaking ABIs , regressions, etc, and with apps linking against lib.so.r, or worse, lib.so (instead of lib.so.r.n), well, the linux recipe for disaster (imho). Again, maybe all this argument is invalid for well-established system libraries like libGL, but i just don't know...
PS
Qt example: Qt Canvas removed in 5.12 -> 5.13 (there are many such situations, this is one that i remember. Or see the first comment from https://www.qt.io/blog/qt-5.15-released : "Moving from 5.6 to 5.9, and then from 5.9 to 5.12 took us weeks, for various reasons - changed behaviour of QML components, heavy bugs,..." etc. And then they have the nerve to say things like "As the last release of the Qt 5 series, we wanted to make sure that Qt 5.15 is a great release that you can easily upgrade to with your ongoing projects. It is, as always, fully backward-compatible with previous Qt 5 releases." (https://www.qt.io/blog/qt-5.15-released). Say what? How can it be backwards compatible if it has a module removed? Well, it is what it is...
