Code::Bocks 10.05 SDL_image setup woes - "Undefined reference to IMG_Load"

Hello, forum. I have been setting up SDL according to the tutorials at lazyfoo.net, and I have been banging my head against an error for the better part of four hours to avail. I've read a number of threads online written by folks with the same problem (Including a recent one here: http://cboard.cprogramming.com/game-...libraries.html), and none of their fixes have worked for me.

I have followed the instructions on lazyfoo to the letter (aside from extracting to a different directory), but I get an "undefined reference to IMG_Load" when I try to use the SDL_image library. (I got the main SDL libraries working perfectly in tutorial 1.) My linker settings are set up to direct codeblocks to the directory with the three SDL .a library files in it, and I can access those three just fine. I have added the file SDL_image.lib to that directory, and tacked -lSDL_image onto the end of my "Other Linker Options" in global compiler settings.

The image header file has been put in with the rest of my SDL .h files, and codeblocks has no difficulty finding that. The only difference between the main libraries and the image library is that the image file is a .lib while the main library files are .a files. (See attached images)

All of my .dll files have been put in the directory with my project.

This has been driving me mad for over a day now. Can anybody see some stupid mistake that I have made?

(I have screen shots of my linker/search directory set up, and where I've stored all of my files)

Thanks, folks.

Rename SDL_image.lib to libSDL_image.a. I seem to remember that `lib` prefix is mandatory for GCC toolchain. This should work if SDL_image.lib was compiled as C static library. If it's compiled as C++ all bets are off due to differences in name decoration schemes between GCC and MSVC.

Note that you still specify `-lSDL_image` as an additional command line option. Not `-llibSDL_image.a`. `lib` prefix and `.a` suffix is added by the toolchain automatically. See here for more relevant info.

I have exactly the same problem. I'm using Eclipse, but I can't compile using the command line either, so I don't think it's Eclipse.

Renaming SDL_image.lib to libSDL_image.a didn't seem to have any effect :(

I think this may be an issue with SDL_image 1.2.12, as I have managed to get it working with SDL_image 1.2.7 (found here:Lazy Foo' Productions)

Try swapping the order that you specify libraries for linking. Sometimes it makes a difference, although usually when the libraries reference each other, so I doubt it's the problem in this case.

It could be a mis-compiled SDL_image too. Different compiler, different settings, maybe the names were C++-mangled, who knows. It might be helpful to see whether the symbol "IMG_Load" is actually present in the library or not. For example on my Linux system if I run "nm /usr/lib/libSDL_image.a | grep IMG_Load" I can quite clearly see a symbol called "IMG_Load" of type "T", which means it's in the text section and hence actually exists. If the name was C++-mangled you'd see other junk as part of the name.

But this is just speculation, as long as you've gotten it working with an earlier version, that's probably good enough. :)

P.S. Standard practice is to use angle brackets when including a standard header file like <string>, rather than saying "string".

Amazingly I was able to find tools that analyze Windows libraries from within Linux in the package binutils-mingw-w64 (I love you, Debian). The two versions of SDL_image, 1.2.7 and 1.2.12, have slightly different symbols but nothing is drastically different between them. Both certainly have an IMG_Load symbol (which is _IMG_Load in the Windows style). So much for that idea.

My only guess would be that you were trying to link with the wrong architecture for 1.2.12: the newer version has both 32-bit and 64-bit libraries, but the older version just has 32-bit. Perhaps even if you have a 64-bit machine you're compiling 32-bit executables. Anyway, maybe try the opposite bit-ness for 1.2.12 if you feel like it. If you're still having troubles post the code you're using plus an attempted command-line compile or screenshots or whatever of the Code::Blocks settings. (Does Code::Blocks save its settings in a convenient config file?)

FAQ-Compiling (errors) - CodeBlocks

It may well be the case that you need to change the order of your libraries in the list, try the image library at the top

Alright guys, how's it going?


I'm having the exact same issue as him. I had used SDL and SDL_Image a few times in the past; yet upon installing it on this computer, it just doesn't seem to work at all.


I'm running Windows 7 Home Premium, and I'm using Code::Blocks 10.05 with MinGW.
I'm using SDL 1.2.15, and SDL_Image 1.2.12; I've attempted using both 32-bit and 64-bit versions.
Running SDL alone with its standard functions works just fine; but the moment I try to use a function from an extension, I get the 'undefined reference' error message.
Changing the library listing order does not change anything; changing SDL_image.lib to SDL_image.a didn't seem to work either, giving me a different error.


All pictures related are here.


Attachment 11451
Attachment 11446
Attachment 11447
Attachment 11448
Attachment 11449
Attachment 11450

Quick Reply, I used to use SDL (available in C) and switched to SFML (available in C, C++ natively). Not everyone knows about it, but Laurent Gromilia is the maintainer. He's super responsive and the SFML community is very active. Don't get me wrong, Sam Lantinga is a freakin' genius. I actually like both packages.

Simple DirectMedia Layer

SFML - Simple and Fast Multimedia Library