Removing -lGL from the default linker options in qt creator

gyll

When i compile a project in qt creator (i have the qtcreator-4.15.2 online install, together w/ online install of qt-5.15.2 kit) the link command (the last step in the build process) appends -lGL to the libraries. However, my app does not use the gl library (well, i guess it doesn't use it because if i manually remove -lGL from the Makefile in the project folder then the project links and runs okay - am i right with this assumption?).

My question is, how/where can i change the default link libraries that qt creator uses for linking my applications in order to remove -lGL (again, i can do this in the Makefile qt creator generates after each "rebuild project", but it's obviously cumbersome to do this after each "rebuild project")

sierdzio

It's probably qmake adding that flag, not Qt Creator.

Qt 5 requires OpenGL to run so if your app is a Qt app, the -lGL is necessary.

gyll

@sierdzio yes, it's qmake that somehow generates that line and qt creator only invokes the command, but my question was how do i change what qmake makes the linker use.

as for the gl library, no, qtcreator does not use it, it works just fine w/o it, and since my app links without it that means my app does not use it either. some components of qt do require gl, but i'm not using those components, i'm not planning to use them, so i don't want to link my app against gl.

My question is how do i get rid of that library in the linker command, not whether my app will link and work or not if gl is not linked.

sierdzio

OK, so which Qt modules do you use?

qmake includes GUI module by default, which depends on OpenGL. So if you don't use gui, you should force it out of qmake, by setting your modules explicitly:

QT = core network

Notice the = - not += or *=. This way you make sure gui module is not included, and so -lGL should vanish (you need to re-run qmake of course, and clean up any cache, stash files).

gyll

@sierdzio no, as i said, qtcreator itself (which is obviously a GUI app) does not require gl to be installed (i have "minimal install" xubuntu-21.04)

my app has
QT += core gui
QT += multimedia multimediawidgets
QT += widgets
and links and runs okay without -lGL (i manually removed it from the Makefile of the project)

if i leave the autogenerated Makefil (with -lGL) then the app won't link (missing gl lib), if i manually remove the -lGL from the Makefile then the app links and runs ok

so what i want to know where are these defaults, and if i can change them.

sierdzio

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 -=-lGL

qtcreator 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!

SGaist

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).

gyll

@sierdzio unfortunately LIBS -=-lGL doesn't do the trick, it still links against gl...

gyll

@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 -lpthread

and 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 -lpthread

and no errors and the app runs just fine (the app is GUI, it even contains drawings)..

sierdzio

Run ldd on 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.

gyll

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?

sierdzio

@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.

gyll

@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...)

SGaist

@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

@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...