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?
Related
When I use the function .loadFromFile(), i get the following error:
undefined reference to `sf::Texture::loadFromFile(std::__cxx11::basic_string, std::allocator > const&, sf::Rect const&)'|
I have already tried different versions of SFML, and according to their website I'm using the correct one.
Here is my setup:
codeblocks-17.12mingw-setup.exe => download for codeblocks
SFML-2.4.2-windows-gcc-4.9.2-tdm-32-bit => SFML I am using
Here are my settings:
in the compiler tab
in the linker tab
The linking should be ok, as all the other SFML functions work. I have read that it could be because of SFML being compiled by a different compiler than mine? How can I check that? Is it something else that causes this problem?
here is the code :
#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>
#include <SFML/Audio.hpp>
#include <SFML/Network.hpp>
#include <SFML/Window.hpp>
#include <SFML/System.hpp>
using namespace sf;
int main () {
Texture texun;
texun.loadFromFile("C:\\Users\\j_hyl\\OneDrive\\Bureaublad\\Webdev\Apps\\Drive\\sprite.bmp");
return 0;
}
you have to link to sfml-graphics.lib or if your configuration is debug you have to link with sfml-graphics-d.lib and you have to copy the sfml-graphics-2.dll and sfml-graphics-d-2.dll(if debugging conf.) to the folder where your executable is
I have been unable to compile a basic class file to generate a window using SDL2, using both brew and compiling from the SDL site using using...
#include <SDL2/SDL.h>
at the top of the file.
Have also used...
#include <SDL/SDL.h>
#include "SDL"
among others and nearly always get this error
./src/window.cpp:1:10: fatal error: 'SDL2/SDL.h' file not found
#include <SDL2/SDL.h>
Something should have worked and just hasn't.
I'm using C++ and Opengl, and I'm trying to use SOIL, but when I compile, I get undefined reference to glBindTexture, glTexImage2D, etc. However, this is only coming from SOIL.c, not my own source code. This is what the error produces:
http://pastebin.com/sKrQaBhz
My graphics card is NVIDIA GeForce GTX 680 and my drivers are fully updated. I have everything linked and I'm using premake to manage my project. I'm developing on a linux machine, however, I'm trying to cross compile it onto my windows machine, which gives this error. If I compile it on linux, it's completely fine. This is my premake4.lua file:
http://pastebin.com/T4hsbdz0
My include files is this:
#include "opengl/gl_core_3_3.hpp"
#include <GLFW/glfw3.h>
#include <SOIL/SOIL.h>
#include <glm/glm.hpp>
#include <glm/gtx/transform.hpp>
#include <glm/gtc/type_ptr.hpp>
#include <iostream>
#include <cstdio>
#include <cstdlib>
#include "loadshader.hpp"
I'm using mingw32 to compile my code. Before I was using SOIL, everything was fine. I downloaded SOIL from their webpage at lonesock.net, which I then copied over the libSOIL.a and their include files, but it just doesn't work.
Links order matters for g++.
Try this order:
links { "SOIL", "glfw3", "opengl32", "gdi32", "glu32" }
(edit: fixed the OP answer according to the duplicated question in Premake forum: http://industriousone.com/topic/how-use-premake-compile-static-library)
Looking at SOIL homepage, they said that it must be linked staticly. So, instead of using dynamic linking ('-l' in gcc compiler), try to specify the full path of the library.
This post illustrate what I want to say: https://stackoverflow.com/a/4156190/2293156
gcc -lsome_dynamic_lib some_static_lib.a code.c
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.
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...