I'm trying to link GLEW (with SDL and OpenGL - note, not SDL's implementation of OpenGL) in Qt Creator via a QMake file, though I'm not having much luck. No matter what I try, I seem to get the same string errors which deals with conflicting declaration problems stemming from a few typedefs. What I'd like to know is why this is happening, along with what can be done about it.
Example
/usr/include/SDL/SDL_opengl.h:4855: error: conflicting declaration ‘typedef void (* PFNGLFRAGMENTLIGHTFVSGIXPROC)(GLenum, GLenum, const GLfloat*)’
/usr/include/GL/glew.h:12201: error: ‘PFNGLFRAGMENTLIGHTFVSGIXPROC’ has a previous declaration as ‘typedef void (* PFNGLFRAGMENTLIGHTFVSGIXPROC)(GLenum, GLenum, GLfloat*)’
Is this because I'm linking with SDL (seeing as how it has OpenGL support), or is there something else going on here?
Qmake File
QT += core
LIBS += -lSDL -lSDL_image -lopengl32 -lGLU -lGLEW
stdafx.h
#pragma once
/*************/
/* #includes */
/*************/
//GL / SDL
#include <GL/glew.h>
#define GLEW_STATIC
#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glext.h>
#include <SDL/SDL.h>
#include <SDL/SDL_opengl.h>
//STD
#include <iostream>
#include <fstream>
//Qt
#include <QListIterator>
#include <QMapIterator>
#include <QVector4D>
#include <QColor>
/********************/
/* Using Statements */
/********************/
using std::cout;
using std::endl;
using std::cin;
using std::fstream;
stdafx.cpp
#define GL_GLEXT_PROTOTYPES
The only solution to your problem is not to use one (either GLEW, or SDL_opengl), or at least do not include both GL/glew.h and SDL/SDL_opengl.h headers in any source or header file.
I have had similar issues before which we "solved" by defining NO_SDL_GLEXT before the inclusion of <SDL/SDL_opengl.h>, so:
#define NO_SDL_GLEXT
#include <SDL/SDL_opengl.h>
I say "solved", because it made the errors go away, but I never investigated possible side-effects or problems (we ended up moving away from SDL shortly after that and never really used it anymore). Perhaps worth a try...
Related
I'm having a strange linking issue after I included inotify in my program to monitor changes to a filesystem. The project includes <fcntl.h> in many other source files. However, when I include <sys/inotify.h> in the source file which is doing the directory monitoring, I get this error:
/usr/include/fcntl.h:30:1: error: expected initializer before ‘extern’
__BEGIN_DECLS
My project uses CMake, although that doesn't seem to be relevant for finding inotify. It IS finding the inotify declarations to my knowledge, since when I included , it threw an error that inotify_init() and the other functions I used were not defined. Inotify includes fcntl and is partially built on top of some of the functionality there, so my first thought was that it's importing a different version of fcntl than the rest of my program.
In ObjectManager.h:
#ifndef MANAGE_OBJECT_H
#define MANAGE_OBJECT_H
#include "config.h"
//includes all lua headers under extern 'C'
#include <lua.hpp>
#include <list>
#include <unordered_map>
#include <pthread.h>
class ObjectManager //...
The only thing that changed was ObjectManager.cc, with the addition of sys/notify and the implementation of the watcher (not included because this is a linking issue):
#include "config.h"
#include "ObjectManager.h"
#include "Control.h"
#ifdef OBJECT_MANAGER_ENABLED
#include <string.h>
#include <stdio.h>
#include <dirent.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <vector>
#include <unistd.h>
#include <fstream>
#include <sys/inotify.h>
//... inotify implementation
Where Control.h declares #include <fcntl.h>.
This is the closest issue I found, related to some problems in the implementation of different fcntl headers for userspace usage. https://lkml.org/lkml/2008/9/16/98
The same problem occurs on Linux 2.6 running on Centos 6 and Linux 4.0 running on Centos 7.
Any ideas on what is causing this error and how to successfully include inotify?
Resolution: A function definition lacked a semicolon at the END of ObjectManager.h right before a #endif, and the resulting GCC error that propagated through the next includes in a complicated manner, resulting in a strange preprocessor error in fcntl.h.
I've been developing using C++ and SDL2 on Linux and have been using the following form to include SDL2 in my headers :
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
However, I now have need to develop on Windows too, which has a different include declaration. I've read up on it as best I can and have successfully included SDL using #include "SDL.h" and passing -I/usr/include/SDL2 into my makefile. This works fine for SDL, but seems to break SDL_image.
Using :
#include "SDL.h"
#include "SDL_image.h"
results in a long list of errors starting with
undefined reference to `IMG_Load'
Using
#include "SDL.h"
#include <SDL2/SDL_image.h>
with the -lSDL2_image flag results in
undefined reference to symbol 'SDL_FreeSurface'
Both of these errors I know are to do with SDL_image. The only thing that seems to work is
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
with the -lSDL2 -lSDL2_image when compiling, but I'd rather avoid that if possible so that I don't have to use #ifdef to compile on both Linux and Windows.
Can anyone point me in the right direction as to where I'm going wrong please?
I get the compiler error __declspec(align('16')) won't be aligned.
When I click the error, Visual Studio sends me to GLM_IMPLEMENT_SCAL_MULT(vec4), which is on the scalar_multiplication.hpp file.
What is the cause for this compiler error? How can I fix it?
Note: Could it be some kind of conflict with the includes? I have several includes in a header file. The commented one is the one that gives the error.
// OpenGL Math library
#include <glm/glm.hpp>
#include <glm/gtc/matrix_transform.hpp>
#include <glm/gtc/type_ptr.hpp>
//#include "glm/ext.hpp" // For printing matrices
#include <SFML/Graphics.hpp>
#include <GL/glew.h>
I'm trying to use Vertex Buffer Objects in OpenGL (in Code::Blocks) but appareantly you need to to do extra steps to actually use these since I kept having "glGenBuffers was not declared in this scope" errors so after some searching I found out that you can use these 'extended' functions by installing the loading library: GLEW, that handles these problems for you.
Here's what I did: I downloaded GLEW Windows binaries. Placed the glew32.dll inside my Windows/System32 folder and added glew32 to my MinGW's lib folder and added the includes to the MinGW's include folder as well. Just to be safe I also manually added the search directories for lib and include in Code::Blocks as well. Also added '-lglew32' in my linker options.
I've included Glew and Glut as follows:
#ifndef INCLUDES_H_INCLUDED
#define INCLUDES_H_INCLUDED
/* Main Header file that contains all the HEADER */
#include <windows.h>
//Some Main constants
#define PI 3.14159265
//Standard includes
#include <stdio.h>
#include <string>
#include <algorithm>
#include <math.h>
#include <iostream>
#include <vector>
#include <ctime>
using namespace std;
// Open GL and GLUT
#include <gl/glew.h>
#include <gl/glut.h>
/* Game Headers */
#include "Game.h"
#include "Functions.h"
#endif // INCLUDES_H_INCLUDED
As far as I'm concerned everything should work now but when compiling I get the following error:
'GLAPI' does not name a type
My main function that initialises glut and glew
int main(int argc, char* args[])
{
// #1: GLUT window initialization
glutInit(&argc, args);
glutInitDisplayMode(GLUT_RGB|GLUT_DOUBLE);
glutInitWindowSize(width, height);
glutInitWindowPosition(width/2, height/2);
glutCreateWindow("OpenGL 3D Programming.");
//glutFullScreen(); //optional
// #2: Registering callbacks
glutReshapeFunc(reshape);
glutDisplayFunc(display);
glewInit();
// #3: GLUT main loop
game.init(width, height);
glutMainLoop();
return 0;
}
Complete listing of build options in Code::Blocks
-lglu32
-lfreeglut
-lglew32
-lwinmm -lgdi32
-lmingw32 -lopengl32
-static-libgcc -static-libstdc++
I'm completely stuck right now and OpenGL is making it quite hard for me to start learning OpenGL using Vertex Buffers at the moment. Is there something I've done wrong that I'm missing?
UPDATE
Oké, I got something working at the moment. I added all the includes and libraries to the Code::Blocks/mingw folder as well (instead of 'only' the C:/MinGW folder) and lost my GLAPI error.
I'm not sure if it is a failproof build at the moment since I'm not quite sure about all the steps I've used but for now it seems like it's working.
When i include GdiPlus.h,Pen class is undefined.
But GdiPlus.h includes GdiPlusPen.h
...
#include "GdiplusImageAttributes.h"
#include "GdiplusMatrix.h"
#include "GdiplusBrush.h"
#include "GdiplusPen.h"
#include "GdiplusStringFormat.h"
#include "GdiplusPath.h"
...
When i include GdiPlusPen.h myself, it works. Can i use it safely?
Question: is this because of my VC++ being express install?
8 days left until activation prompt :(
Anyone having same problem?
Windows XP sp-3, pentium-m centrino.
No, #including GdiplusPen.h directly isn't correct. The gdiplus classes live in a namespace named "Gdiplus". Either use that namespace explicitly (like Gdiplus::Pen) or make it look like this in your .cpp file:
#include <gdiplus.h>
using namespace Gdiplus;