I am trying to get an OpenGL program working on both linux and windows.
Here's my code [file=main.cc]:
#include <iostream>
#include "GL/glew.h"
using namespace std;
int main(int argc, char *argv[]){
cout << "Hello World\n";
return 0;
}
Simple enough. I'm on Linux and using
g++ main.cc -lGL -lGLEW -lSDL2
to compile my program. It works perfectly fine and if I run ./a.out I get a Hello World on my screen.
Then I try to compile it on Linux for Windows using the command
x86_64-w64-mingw32-g++ main.cc -lGL -LGLEW -LSDL2
Then however i get the error:
main.cc:3:21: fatal error: GL/glew.h: No such file or directory
#include "GL/glew.h"
^
compilation terminated.
I've already tried adding the -I/inclulde/path option with paths like /usr/include /usr/include/GL usr/include and the like, yet nothing wants to compile.
The Libraries that I'm using (or planning to) were installed using
#apt install libgl-dev libglew-dev libsdl2-dev
Any help would be very much appreciated (although I feel this is an incredibly easy fix that I'm just too stupid to figure out on my own)
Related
I use the Emacs text editor for editing my files, and have been looking into using OpenGL in my programs. However, I have had trouble including the GLFW header into my program.
Here is my code for the #include statements and essentially test if the files linked properly, which comes from the hyperlink later on.
#include <iostream>
#include <GL/glew.h>
#include <GLFW/glfw3.h>
using namespace std;
int main()
{
glewExperimental = true;
if(!glfwInit())
{
cout << "Failed to initialize" << endl;
return -1;
}
return 0;
}
I hit M-x compile then g++ file.cpp -lglut -lGL -lGLEW -lGLU -o file.out and get the following error
g++ anotherGL.cpp -lglut -lGL -lGLEW -lGLU -o anotherGL.out
anotherGL.cpp:5:10: fatal error: GLFW/glfw3.h: No such file or directory
#include <GLFW/glfw3.h>
^~~~~~~~~~~~~~
I followed the instructions for downloading the OpenGL tutorial page, under the section Building on Linux, but the instructions diverge after it moves on to the section where the packages are linked to the IDE.
(http://www.opengl-tutorial.org/beginners-tutorials/tutorial-1-opening-a-window/)
Is there a M-x command I can use in place of what I have to perform the link?
On "debian" and "red hat" systems, the include file GLFW/glfw3.h is under /usr/include a la /usr/include/GLFW/glfw3.h. Your include statement is correct as /usr/include is implicitly searched by gcc/g++. You've just missed installing the glfw development package. On "debian" or apt-based systems this is in libglfw3-dev. On "red hat" or rpm based systems this is glfw-devel. You may also need to add the flag -lglfw to your compile command.
I wanted to start learning to program with SDL. So I download x86 for windows,
put all the lib and the include in MinGW. But when I compile it doesn't know the SDL functions exist.
# define SDL_MAIN_HANDLED // somehow it want it to not define its own main
#include <iostream>
#include <sdl2/SDL.h>
using namespace std;
int main( int argc, char* argv[] ) {
SDL_SetMainReady(); // just for check
return 0;
}
I read that the linking need to be in specific order (mingw32, SDL2main and then libSDL2), But I think Eclipse run a wrong compiling command.
The eclipse command:
g++ -O0 -g3 -Wall -c -fmessage-length=0 -o "src\\fire.o" "..\\src\\fire.cpp"
g++ -o fire.exe "src\\fire.o" -lmingw32 -lSDL2main -llibSDL2
src\fire.o: In function `main':
C:\Or\C++\Projects\fire\Debug/../src/fire.cpp:16: undefined reference to `SDL_SetMainReady'
collect2.exe: error: ld returned 1 exit status
Do you think I miss something?
I think you need to change -llibSDL2 to -lSDL2.
Ok I solve it. I'm not sure if the problem was lack of support on 32 bit or the fact that minGW and SDL were from different compilers that probably didn't match..
But what I did is to delete minGW from my pc and download WinBuild. WinBuild its a download manager that offer a lot of libs and tools, include minGW64 bit and SDL.
The advantage is that they were all compile from the same compiler with the same configurations.
after that i change the path to minGW in to the new 64 bit path inside WinBuild folder, add g++ from Winbuild the to the path as well and restart.
Then, adding and linking work without any problem!
I still need to put # define SDL_MAIN_HANDLED on the start to make it work, but its work!
I would like to develope an application using C++ and OpenGL for Windows 64bit.
I am using the following Compiler x86_64-w64-mingw32-g++.
The following code snippet (Test.cpp) is sufficient to trigger the error I get:
#include <GL/gl.h>
int main(int argn, char **argv) {
glClear(GL_COLOR_BUFFER_BIT);
}
(I know this code is meaningless, but it is sufficient to trigger the error during linking.)
I use the following Makefile:
Test:
g++ -lopengl32 -o Test Test.cpp
This yields the following error:
undefined reference to `__imp_glClear'
I have no clue what I am missing, and would be very thankfull for any advice.
For me the g++ main.cpp -o run.exe -lopengl32 seems to work just fine, so you most likely wont need -Wl,--enable-stdcall-fixup to compile it.
I setup SDL2 under C++ CDT Eclipse.
I added the include path "........SDL2-2.0.3\i686-w64-mingw32\include", the library path "........SDL2-2.0.3\i686-w64-mingw32\lib" and added the libraries 1."mingw32" 2."SDL2main" 3."SDL2".
So now, if I add a main.cpp with this content:
#include <SDL.h>
int main(int argc, char* args[])
{
return 0;
}
I can build the project fine, but if I use this:
#include <SDL.h>
int main()
{
return 0;
}
The project can't build and I get this error:
Info: Internal Builder is used for build g++ "-IO:\Eclipse CDT
Workspace\SDL OpenGL Lab\Libraries\SDL2\include\SDL2" -O0 -g3
-Wall -c -fmessage-length=0 -o main.o "..\main.cpp" g++ "-LO:\Eclipse CDT Workspace\SDL OpenGL Lab\Libraries\SDL2\lib" -o
"SDL OpenGL Lab.exe" main.o -lmingw32 -lSDL2main -lSDL2 O:\Eclipse
CDT Workspace\SDL OpenGL
Lab\Libraries\SDL2\lib/libSDL2main.a(SDL_windows_main.o): In function
console_main':
/Users/slouken/release/SDL/SDL2-2.0.3-source/foo-x86/../src/main/windows/SDL_windows_main.c:140:
undefined reference toSDL_main' collect2.exe: error: ld returned 1
exit status
I simply wonder me why this error is depending on my main method, I want to use the main method I want.
Why this is so, how I can fix this ?
Sorry, you're stuck with it. I also preferred a simpler main, but SDL doesn't support it.
Here's a little more on SDL and main in the Windows world. It doesn't say why you need their version of main -- but you do.
I get "Undefined reference to 'SDL_main'" ...
Make sure that you are declaring main() as:
#include "SDL.h"
int main(int argc, char *argv[])
https://wiki.libsdl.org/FAQWindows
I had the same problem and had to go through a lot of manipulations.
What I have found is the simple line #define SDL_MAIN_HANDLED before calling SDL.h. SDL has his own main that's why, I think.
For example, in my .h files, I write everytime this :
#include <stdio.h>
#include <stdlib.h>
#define SDL_MAIN_HANDLED
#include <SDL.h>
#include <SDL_image.h>
#include <SDL_ttf.h>
I've been learning SDL for a little time, and now I've decided to try out SDL2, mainly to try its hardware acceleration. But the problem is, I can't compile it at all, while the same code compiled correctly with SDL1.2.
The sample code is:
#include "SDL/SDL.h"
int main( int argc, char *args[] )
{
SDL_Init(SDL_INIT_EVERYTHING);
SDL_Quit();
return 0;
}
With the original linker settings: -lmingw32 -lSDLmain -lSDL
everything compiles.
But as soon as I change #include "SDL/SDL.h" to #include "SDL2/SDL.h"
and change linker settings to
-lmingw32 -lSDL2main -lSDL2
I get the errors:
obj\Debug\main.o||In function `SDL_main':|
main.cpp|5|undefined reference to `SDL_Init'|
main.cpp|8|undefined reference to `SDL_Quit'|
libmingw32.a(main.o):main.c:(.text.startup+0xa7)||undefined reference to `WinMain#16'|
I've got SDL1.2 installed in C:/SDL-1.2.15 and SDL2 installed in C:/SDL2
In search directories, I added both SDL1.2 and SDL2 Include and Lib folders.
I'm not sure if this will work, but if you are using the "x86_64-w64-mingw32" folder, try using the other one (the one with i686) this helped me. I was having the EXACT same problem as you, and using literally, to the line, the same test code as you. I hope this helps.