SDL2 won't link properly - c++

I'm using Code::Blocks, that's my code:
#include "SDL2/SDL.h"
int main(int argc, char* args[]) {
SDL_Init( SDL_INIT_EVERYTHING );
SDL_Quit();
return 0;
}
I'm building like:
mingw32-g++.exe -o C:\..\main.exe C:\..\main.o -lmingw32 -lSDL2main -lSDL2
And getting that:
undefined reference to "SDL_Init"
undefined reference to "SDL_Quit"
I'm pretty sure the linker finds the libs cause if I change them to something random it complains "can't find whatever".

A bit late, but I just stumbled over a similar problem on Linux.
This results in linker errors:
g++ $(pkg-config --cflags --libs sdl2) sdl2test.cpp
sdl2test.cpp:(.text+0x11): undefined reference to `SDL_Init'
sdl2test.cpp:(.text+0x20): undefined reference to `SDL_GetError'
sdl2test.cpp:(.text+0x34): undefined reference to `SDL_Quit'
This works:
g++ sdl2test.cpp $(pkg-config --cflags --libs sdl2)

even if this is an Linux Problem, i came throug this post via google.
Mayb it could help someone else: i had the same Problem with Windows XP 32bit Codeblocks: Mingw + SDL2 and i fixed it after i copied the right SDLFolders (include, lib...) to the mingw-folder. The reason why i trapped to this pifall is that the naming of the SDL-Rootfolder, out of the DEV-Pack is a bit confusing. You got a "x86_64-w64-mingw32"-Folder which is for 64bit Compiler and "i686-w64-mingw32" which is for 32bit Compiler (like the moste still are). i messed this up because of the "x86..."naming, still dont know why they are writing it this way.
After overwriting the right files it works fine for me.

Are you sure you have your libraries in you path ?
Try adding -LC:/whatever/ with the folder that actually contains you libSDL2.a and other *.a to your compiler's arguments.

Related

Freeglut 64 bit program linking errors

I'm trying to compile a 64 bit version of an OpenGL C++ program using freeglut. I followed the exact instructions on this website to set up freeglut with MinGW. I have the header files in C:\MinGW\include\GL, I have the 32 bit libraries in C:\MinGW\lib and 64 bit libraries in C:\MinGW\lib\x64, and I have the 64 bit freeglut.dll in my project directory. However, even the simplest of OpenGL programs don't link successfully...
My code is minimal:
// test.cpp
#include <GL/glut.h>
int main(int argc, char *argv[]) {
glutInit(&argc, argv);
}
And I compile it with the exact commands given on the readme/on the website:
g++ -c -o test.o test.cpp -I"C:\MinGW\include"
g++ -o test.exe test.o -L"C:\MinGW\lib\x64" -lfreeglut -lopengl32 -Wl,--subsystem,windows
(except of course I changed the directories and changed gcc to g++)
The compile runs fine, but linking throws these error messages:
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: test.o:test.cpp:(.text+0x1c): undefined reference to `_imp____glutInitWithExit#12'
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: test.o:test.cpp:(.text+0x3f): undefined reference to `_imp____glutCreateWindowWithExit#8'
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: test.o:test.cpp:(.text+0x61): undefined reference to `_imp____glutCreateMenuWithExit#8'
collect2.exe: error: ld returned 1 exit status
I've tried to change -lopengl32 in the command to -lopengl64 and -lopengl, but the linker couldn't find those libraries.
I can't answer your specific case, but another approach would be to use mingw-w64, with MSYS2 as a package manager. The old mingw.org project is not well maintained, unlike mingw-w64 and the MSYS2 package database. There is probably some mismatch between how your precompiled binaries were built and the compiler you are currently using.
On my system I compiled your code with g++ -o gl gl.cpp -lfreeglut and it worked first time .
How to install MinGW-w64 and MSYS2?
Then use pacman -Ss glut to find the freeglut package.

gtest and MinGW linkage

I've made a simple main to check if gtest was correctly linked and got "undefined reference" errors. The first line in the main function throws an undefined reference to `testing::InitGoogleTest(int*, char**)'.
#include <gtest/gtest.h>
int main(int argc, char* argv[])
{
testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
I have successfully built a gtest Code::Block project with the help of cmake and without the pthread library. Then, I compiled everything with MinGW. I took the libgtest.a libgmock.a and linked them in my Code::Block project with no problems. I also specified the include directories and the binary directories. Is it possible that I need to include gtest_main.a too?
The build log (I added "..." to hide long chains of folders):
"obj\Debug gtest\MainTest.o" -lsfml-graphics-s-d -lsfml-window-s-d -lsfml-network-s-d -lsfml-audio-s-d -lsfml-system-s-d -lglew -lgtest -lgmock -lws2_32 -lopenal32 -lsndfile -lgdi32 -lwinmm -lfreetype -ljpeg -lglu32 -lopengl32
obj\Debug gtest\MainTest.o: In function main':
D:/.../Templates/SFML 2_2 BasicScene/MainTest.cpp:5: undefined reference totesting::InitGoogleTest(int*, char**)'
obj\Debug gtest\MainTest.o: In function Z13RUN_ALL_TESTSv':
D:/.../googletest/googletest/include/gtest/gtest.h:2237: undefined reference totesting::UnitTest::GetInstance()'
D:/.../googletest/googletest/include/gtest/gtest.h:2237: undefined reference to `testing::UnitTest::Run()'
I finally found it! It was tricky: as I am using Windows 7 and installed multiple compilers (3 versions of MinGW and 2 of TDM), my PATH got all mixed up. When I was using cmake-gui 3.3, I was using the default compiler, which was MinGW 4.7 when I installed Code::Blocks. After installing all the compilers mentionned above, the default compiler path changed for a higher version of MinGW. Linking with a library that was compiled with a newer version of MinGW didn't cause the library to not be found, but instead caused linking errors.
In conclusion, I was using two differents versions of the same compiler.

Linking project on MinGW Netbeans 7.0 and SDL 2 on Windows

As I tried to upgrade from my graphics programming from "legacy openGL" x "SDL 1.x" to OpenGL3+ x SDL2 and I came across linking problems. I tried many linking parameters but nothing seems to work.
I tried SDL1 linking params: linking listing 1
-lmingw32 -lSDLmain -lSDL
It works fine with this code: code listing 1
#include <SDL2/SDL.h>
int main(int argc, char **argv)
{
if(SDL_Init(SDL_INIT_VIDEO) < 0)
{
SDL_Quit();
return -1;
}
SDL_Quit();
return 0;
}
but when I add SDL2 codes to it like this: code listing 2
#include <SDL2/SDL.h>
int main(int argc, char **argv)
{
SDL_Window* window(0);
if(SDL_Init(SDL_INIT_VIDEO) < 0)
{
SDL_Quit();
return -1;
}
window = SDL_CreateWindow("Test SDL 2.0", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 800, 600, SDL_WINDOW_SHOWN);
SDL_DestroyWindow(window);
SDL_Quit();
return 0;
}
I get linking errors: error listing 1
g++ -o dist/Debug/MinGW-Windows/sdl2 build/Debug/MinGW-Windows/main.o -lmingw32 -lSDLmain -lSDL
build/Debug/MinGW-Windows/main.o: In function `SDL_main':
C:\Users\Paikuhan\Documents\NetBeansProjects\SDL2/main.cpp:21: undefined reference to `SDL_CreateWindow'
C:\Users\Paikuhan\Documents\NetBeansProjects\SDL2/main.cpp:23: undefined reference to `SDL_DestroyWindow'
collect2.exe: error: ld returned 1 exit status
swaping linking params to this: linking listing 2
-lmingw32 -lSDL -lSDLmain
gives even more errors (I won't write them down). Adding a '2' to the params like this: linking listing 3
-lmingw32 -lSDL2main -lSDL2
gives me more linking errors than without the 2s: error listing 2
g++ -o dist/Debug/MinGW-Windows/sdl2 build/Debug/MinGW-Windows/main.o -lmingw32 -lSDL2main -lSDL2
build/Debug/MinGW-Windows/main.o: In function `SDL_main':
C:\Users\Paikuhan\Documents\NetBeansProjects\SDL2/main.cpp:14: undefined reference to `SDL_Init'
C:\Users\Paikuhan\Documents\NetBeansProjects\SDL2/main.cpp:16: undefined reference to `SDL_Quit'
C:\Users\Paikuhan\Documents\NetBeansProjects\SDL2/main.cpp:21: undefined reference to `SDL_CreateWindow'
C:\Users\Paikuhan\Documents\NetBeansProjects\SDL2/main.cpp:23: undefined reference to `SDL_DestroyWindow'
C:\Users\Paikuhan\Documents\NetBeansProjects\SDL2/main.cpp:24: undefined reference to `SDL_Quit'
c:/programs/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/libmingw32.a(main.o): In function `main':
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/main.c:91: undefined reference to `WinMain#16'
collect2.exe: error: ld returned 1 exit status
as if no single SDL functions were found and I do have the libraries (libSDL2.a, libSDL2.dll.a, libSDL2.la, libSDL2main.a, pkgconfig\sdl2.pc) in the lib directory. I also tried using this set of params in netbeans: linking listing 4
$(pkg-config --cflags --libs sdl2)
and it doesn't do any good. Can anyone please help me on this. Thank you!
Problem Solved! I tried to troubleshoot the linking errors. Now everything works fine!! LazyFoo's tutorial has the answer "Most importantly i686-w64-mingw32 which contains the 32bit library [...] This is important: most compilers still compile 32bit binaries by default to maximize compatibility. [...]". So I re-extracted all the 32bit files in their corresponding directories. Now everything works like a charm. My guess is I used the 64bit libs with the 32bit mingw compiler.
both linking params work fine. this:
$(pkg-config --cflags --libs sdl2)
or this:
-lmingw32 -lSDL2main -lSDL2

GLEW libraries seems to have issues when linking

I'm getting really frustrated now with trying to link this glew Library
Here's the build log:
g++ -o test.exe "src\\test.o" -lglew32 -lglfw -lglu32 -lopengl32
src\test.o: In function `main':
C:\dev\test\Debug/../src/test.cpp:31: undefined reference to `_imp__glewInit#0'
C:\dev\test\Debug/../src/test.cpp:41: undefined reference to `_imp____glewGenVertexArrays'
C:\dev\test\Debug/../src/test.cpp:42: undefined reference to `_imp____glewBindVertexArray'
I've tried moving around which libraries go first in the build command.
This seems to be an issue that others on the internet are having but i cant seem to find any of them that have fixed it
Ok I know it's a bit wierd be answering my own question but here was the issue:
Apparently the errors were occuring in two areas
For a starter, i didn't need glu32 only opengl32 as i beleive glew handled this itself
Secondly, for some wierd reason i had to call
#define GLEW_STATIC
manually before I imported

what I'm including wrong ? undefined reference to al_init_image_addon error,

what I'm including wrong ?
I am using codeblocks + allegro5 + ubuntu 11.10
and getting this 2 errors
undefined reference to 'al_init_image_addon'
undefined reference to `al_init_primitives_addon'|
I did install allegro5 correctly with all the dependencies. The first tutorial on loading the allegro.h works fine, it creates a normal window apart from the xterm window.
I am following the "show in fullscreen tutorial" from the allegro wiki
#include "allegro5/allegro.h"
#include "allegro5/allegro_image.h"
#include <allegro5/allegro_primitives.h>
#include "allegro5/allegro_native_dialog.h"
int main()
{
ALLEGRO_DISPLAY *display = NULL;
ALLEGRO_DISPLAY_MODE disp_data;
al_init();
al_init_image_addon(); // <---------ERROR HERE
al_init_primitives_addon();// < --------ERROR HERE TOO
al_set_new_display_flags(ALLEGRO_FULLSCREEN);
display = al_create_display(disp_data.width,disp_data.height);
al_rest(3);
al_destroy_display(display);
return 0;
}
In the event anyone has this issue, the fix is adding allegro_image-5.0 to your pkg-config path e.g.:
gcc game.c -o game $(pkg-config --cflags --libs allegro-5.0 allegro_image-5.0)
well, after doing a little google search and posting at allegro's homepage I got the correct answer,
I was missing the .so files in the linker section under TOOLS > Compiler&DEbugger > LINKER.
I had to add these lines
/usr/lib/liballegro_dialog.so
/usr/lib/liballegro_color.so
/usr/lib/liballegro_audio.so
/usr/lib/liballegro_image.so
/usr/lib/liballegro_physfs.so
/usr/lib/liballegro.so
/usr/lib/liballegro_font.so
/usr/lib/liballegro_acodec.so
/usr/lib/liballegro_main.so
/usr/lib/liballegro_memfile.so
/usr/lib/liballegro_primitives.so
/usr/lib/liballegro_ttf.so
and `pkg-config --libs allegro-5.0`
see this post for the screenshot.
http://hongouru.blogspot.com/2012/02/solved-allegro5-undefined-reference-to.html