[SOLVED] Problem using LLVM with Qt 5.0.0 within on Ubuntu
-
try strace to see which libs are opened and when?
-
Thanks for the suggestion, Thomas. I didn't know about strace, still it didn't bring up anything useful. Now, I have spent some time googling around and... I have found some kind of a solution to my problem. I guess I should have mentioned that my Ubuntu box is, in fact, an Ubuntu virtual machine running within VirtualBox, and... since Qt 5 now requires OpenGL for any kind of application, well... that can cause problems depending on what you do and it certainly causes problems in my case (because of my use of LLVM). Anyway, the 'solution' consists of using indirect rendering, e.g.
$ LIBGL_ALWAYS_INDIRECT=1 ./myapp
Really not ideal, but at least it's now working fine. (Seriously, why on earth does Qt 5 forces you to use OpenGL in an application which doesn't actually make use of it?!)
-
In Qt4 OpenGL was a "per project" module, but since Qt5 is (almost entirely) all about QML and QtQuick2, OpenGL support is essential and built deep in QtGui. So the solution to get rid of GL dependencies completely is to have a whole separate Qt5 build with no OpenGL support, which will be highly limited in usage, but able to provide QWidget based projects that don't use OpenGL without dependencies on OpenGL.
-
Thanks for the clarification, utcenter.
I can understand the need for OpenGL for QML and QtQuick2, I just wish there had been a way to avoid OpenGL for those of us who don't use QML or QtQuick2.
Then again, it's probably true that, nowadays, we could rightly expect any machine to have proper support for OpenGL. It's just too bad that the VitualBox guys still haven't come up with some decent 3D support after all those years.
Anyway, I might end up using OpenGL in my project, not to mention that I want to be able to use whatever Qt has to offer, so it wouldn't make sense for me to use my own version of Qt 5 with no OpenGL support.
-
I am normally using a Qt build with desktop OpenGL support, by default, Qt normally comes with an ANGLE implementation instead. But I have created another build explicitly for the purpose of building QtGui based applications in order to be able to distribute with minimal external dependencies. The pre-build version of Qt5 comes with a hefty set of dependencies, most of which can be eliminated when not needed. There is a minor inconvenience that the number of different Qt builds you have on your machine grows, but for the time being this is the only way to cut down the number of DLLs you have to ship with your program.
-
Notice that virtualbox has opengl support, I had it running nicely, including composited kwin, on a win7 box, on a previous assignment.
So give that one another try ;) -
@utcenter: indeed, it was a 'shock' when I found out that my application now takes much more space once deployed. This aside, I can't afford building a non-OpenGL version of Qt 5. I need to target Windows, Linux (32 and 64 bits) and OS X, so that would be a bit of a nightmare to manage, especially since I am very likely to use OpenGL at some point.
@Thomas: how do you mean that VirtualBox has OpenGL support? Are you talking about the 3D hardware acceleration? If so, I have tried it: it crashes my Ubuntu 12.04 virtual machine on an OS X host. As for my Ubuntu 12.10 virtual machine, it doesn't crash but it's completely unusable. Bottom line, VirtualBox is great (I have been using it for years), but its 3D support is still really, really bad.
-
Ah, osX, yeah, virtualbox works better on Win.
On MacOS I had to use vmware for getting opengl to work in there :) Which cost some 50 dollars or so. -
I tried both VMWare and Parallels before. I didn't fancy VMWare and was, in the end, leaning towards Parallels, but then it badly crashed on me, so I reverted to VirtualBox.
At the end of the day, everything works fine when I use LIBGL_ALWAYS_INDIRECT and that is what matters to me at this stage. I am not here to fix VirtualBox, just to make sure that my application works on the different platforms I need to support. :)