Qt 5.1 Linux x64 and gcc 4.8.1-1 on Fedora Linux 19 x64
-
I have upgraded to Fedora 19 while preserving my Fedora 17 system.
I launched a verification test of the Qt 5.1 installation on Fedora 19 (gcc 4.8.1-1) and
was very upset to get a compile time error although the same test program compiles and runs
fine on Fedora 17 (Qt 5.1/gcc 4.7.2-2).In the error output it is said that the file <GL/gl.h> cannot be found. The line including
this header is located in qopengl.h, in this block:if defined(Q_OS_MAC)
include <OpenGL/gl.h>
if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_7
define GL_DO_NOT_WARN_IF_MULTI_GL_VERSION_HEADERS_INCLUDED
include <OpenGL/gl3.h>
endif
include <OpenGL/glext.h>
else
define GL_GLEXT_LEGACY // Prevents GL/gl.h form #including system glext.h
include <GL/gl.h>
include <QtGui/qopenglext.h>
endif // Q_OS_MAC
On Fedora 17, by using an #error directive, I have checked that this line is actually reached.
But the Gnome's "Search for Files" utility finds no gl.h file in the (Fedora 17) gcc_64 directory
although the test program compiles fine ! Nor does it find any file containing GL_GLEXT_LEGACY
(which must be checked in gl.h). Could it have something to do with the metaobject compiler ?Be that as it may, this test program which works with gcc 4.7.2-2 does not anymore with gcc 4.8.1-1.
Assuming it is worth being mentioned, "INCPATH" is set (by qmake) to :
-I../../Qt5.1.0/5.1.0/gcc_64/mkspecs/linux-g++
-I../../Qt5.1.0/5.1.0/gcc_64/include
-I../../Qt5.1.0/5.1.0/gcc_64/include/QtWidgets
-I../../Qt5.1.0/5.1.0/gcc_64/include/QtGui
-I../../Qt5.1.0/5.1.0/gcc_64/include/QtCore -
bq. But the Gnome’s “Search for Files” utility finds no gl.h file in the (Fedora 17) gcc_64 directory
No, because it is not part of GCC. "GL/gl.h" is typically part of Mesa on Linux machines and is usually found in the default system /usr/include directory.
bq. Could it have something to do with the metaobject compiler ?
Since we cannot see, and you do not say, what is generating the paraphrased error message it is hard to say. Similarly since we cannot see your project file or code it is hard to specifically diagnose.
Presumably you are contending that Qt did not change through this update and therefore the behaviour of moc has not changed, which would imply this has nothing to do with moc.