Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: Freezeil on November 23, 2007, 02:14:07 am

Title: OpenGL linker problem
Post by: Freezeil on November 23, 2007, 02:14:07 am
Hey everyone,

I've just moved from Visual C++, seeing as how I couldn't deploy my OpenGL applications, so figured I'd try C::B...
Finally got it installed, and the compiler is working, but I get some linking errors:
Code
ompiling: game.cpp
Compiling: main.cpp
Compiling: engine.cpp
Linking console executable: SDLapp.exe
H:\Libs/SDLmain.lib(./Release/SDL_win32_main.obj):C:\SDL-1.2.11\Src\:(.text[_main]+0x0): multiple definition of `main'
C:\MinGW\lib/libmingw32.a(main.o):main.c:(.text+0x0): first defined here
Warning: .drectve `/DEFAULTLIB:"MSVCRT" /DEFAULTLIB:"OLDNAMES" ' unrecognized
.objs\game.o:game.cpp:(.text+0x782): undefined reference to `glLoadIdentity@0'
.objs\game.o:game.cpp:(.text+0x7ad): undefined reference to `glTranslatef@12'
.objs\game.o:game.cpp:(.text+0x7bd): undefined reference to `glCallList@4'
.objs\game.o:game.cpp:(.text+0x7fb): undefined reference to `glLoadIdentity@0'
.objs\game.o:game.cpp:(.text+0x826): undefined reference to `glTranslatef@12'
.objs\game.o:game.cpp:(.text+0x848): undefined reference to `glCallList@4'
.objs\game.o:game.cpp:(.text+0x11da): undefined reference to `glDisable@4'
.objs\game.o:game.cpp:(.text+0x11ec): undefined reference to `glGenLists@4'
.objs\game.o:game.cpp:(.text+0x1403): undefined reference to `gluNewQuadric@0'
.objs\game.o:game.cpp:(.text+0x145c): undefined reference to `glViewport@16'
.....

and so on...
I'm using SDL to open the window, and i've included pretty much everything I can think of, so thought maybe you can help me - am I forgetting something?

Also, how do I get rid of that ".drectve `/DEFAULTLIB:"MSVCRT" /DEFAULTLIB:"OLDNAMES" ' unrecognized" warning?
Title: Re: OpenGL linker problem
Post by: Auria on November 23, 2007, 03:19:42 am
Seems like you didn't link against OpenGL library, what libraries do you link against?
Title: Re: OpenGL linker problem
Post by: Freezeil on November 23, 2007, 09:10:26 am
Well, my include set includes:
Code
#include "SDL\SDL.h" //main SDL loader
#include "SDL\SDL_image.h" //for .PNG and .JPEG support
#include "SDL\SDL_opengl.h" //for opengl functionality

#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glut.h>

#ifdef WIN32
#pragma comment(lib, "SDL.lib")
#pragma comment(lib, "SDLmain.lib")
#pragma comment(lib, "SDL_image.lib")
#pragma comment(lib, "OpenGL32.lib") // Not really needed
#endif

Plus, I'm linking against SDL.lib, SDLmain.lib, SDL_image.lib, SDL_ttf.lib, SDL_mixer.lib, glut32.lib and OpenGL32.lib...
Title: Re: OpenGL linker problem
Post by: thomas on November 23, 2007, 09:56:51 am
Well, my include set includes:
Code
#include "SDL\SDL.h" //main SDL loader
#include "SDL\SDL_image.h" //for .PNG and .JPEG support
#include "SDL\SDL_opengl.h" //for opengl functionality

#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glut.h>

#ifdef WIN32
#pragma comment(lib, "SDL.lib")
#pragma comment(lib, "SDLmain.lib")
#pragma comment(lib, "SDL_image.lib")
#pragma comment(lib, "OpenGL32.lib") // Not really needed
#endif

Plus, I'm linking against SDL.lib, SDLmain.lib, SDL_image.lib, SDL_ttf.lib, SDL_mixer.lib, glut32.lib and OpenGL32.lib...
That's a typical misconception of Visual Studio users. You are not linking against those libraries, just because there is a #pragma directive somewhere in the code.
This only works with the Microsoft compiler, which implements this hack. Thus, if you ever migrate to any other compiler or IDE, everything breaks and burns. Of course that's just what is wanted, too.

There are two solutions for your problem. Either you can just configure Code::Blocks to use the Microsoft compiler, then everything should be as "normal", or you can do things correctly, and add the link libraries to the project options, which is  the standard everywhere.
Title: Re: OpenGL linker problem
Post by: Freezeil on November 23, 2007, 10:07:44 am
As I was saying, I've read the tutorials out there, and I *did* add: SDL.lib, SDLmain.lib, SDL_image.lib, SDL_ttf.lib, SDL_mixer.lib, glut32.lib and OpenGL32.lib, to the linker's list (at Settings -> Compiler and debugger -> Linker Settings)... All of these libraries are added via address, directly...

Plus, i've added a few more (SDL, SDLmain, OpenGL32 and glut32) via "title" only (just as I wrote them), and the error list decreased significantly:
Code
-------------- Build: default in SDL Application ---------------

Compiling: game.cpp
Compiling: main.cpp
Compiling: engine.cpp
Linking console executable: SDLapp.exe
C:\MinGW\lib/SDLmain.lib(./Release/SDL_win32_main.obj):C:\SDL-1.2.11\Src\:(.text[_main]+0x0): multiple definition of `main'
C:\MinGW\lib/libmingw32.a(main.o):main.c:(.text+0x0): first defined here
Warning: .drectve `/DEFAULTLIB:"MSVCRT" /DEFAULTLIB:"OLDNAMES" ' unrecognized
.objs\game.o:game.cpp:(.text+0x1403): undefined reference to `gluNewQuadric@0'
.objs\game.o:game.cpp:(.text+0x1491): undefined reference to `gluOrtho2D@32'
C:\MinGW\lib/SDLmain.lib(./Release/SDL_win32_main.obj):C:\SDL-1.2.11\Src\:(.text[_main]+0x55): undefined reference to `_alloca_probe'
C:\MinGW\lib/SDLmain.lib(./Release/SDL_win32_main.obj):C:\SDL-1.2.11\Src\:(.text[_WinMain@16]+0x181): undefined reference to `_alloca_probe'
C:\MinGW\lib/SDLmain.lib(./Release/SDL_win32_main.obj):C:\SDL-1.2.11\Src\:(.text[_WinMain@16]+0x1c1): undefined reference to `_alloca_probe'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 2 seconds)
5 errors, 1 warnings

What am I doing wrong now?


//edit
Added glu32 to the linker's list and it solved it, now down to only the "_alloca_probe" errors...
Title: Re: OpenGL linker problem
Post by: thomas on November 23, 2007, 10:23:15 am
Adding winmm and mingw32 should remove the _alloca_probe error. I have never had this error, but Google says so :)

The "multiple definition of main" error, again, is one I've not had, but once again Google comes to the help with -Dmain=3DSDL_main.

In general, whenever asking a problem with a build, it is helpful to turn the compiler logging to "full command line" since that provides a lot more information.