Code::Blocks, CImg

Started by
3 comments, last by nife87 12 years, 10 months ago
Hello,

Recently I've downloaded Code::Blocks because I'd like to make projects that are open and multi platform. I want to make a very simple program that uses the C image liberary CImg.
The whole library is included in a single header called :CImg.h". I've included this in the same folder as my project I wish to work on. I have also included the header file in my source code for the project.

The minimum code contained in my main.cpp file looks like this:



#include "CImg.h"
using namespace cimg_library;

int main() {
const unsigned char purple[] = { 255,0,255 };
CImg<unsigned char>(640,400,1,3,0).draw_text(100,100,"Hello World",purple).display("My first CImg code");
return 0;
}



Upon compiling I get the following errors:


obj\Release\main.o:main.cpp|| undefined reference to `SetDIBitsToDevice@48'|
obj\Release\main.o:main.cpp|| undefined reference to `SetDIBitsToDevice@48'|
obj\Release\main.o:main.cpp|| undefined reference to `SetDIBitsToDevice@48'|
obj\Release\main.o:main.cpp|| undefined reference to `SetDIBitsToDevice@48'|
obj\Release\main.o:main.cpp|| undefined reference to `SetDIBitsToDevice@48'|
obj\Release\main.o:main.cpp|| more undefined references to `SetDIBitsToDevice@48' follow|
||=== Build finished: 6 errors, 0 warnings ===|



I'm not used to really working much with external dependencies with Code::Blocks and I've not ventured beyond playing with SFML (which I got working following a tutorial).
I'm working on Windows 7 at the moment if that is of any help. I'm not advanced with C++ but I have an understanding of the core library. Adding dependent libraries is really a headache it seems...
Advertisement
Although I don't know CImg, undefined reference normally means you haven't linked something properly.

Meaning, either it's not there (under more options in build options), in the wrong order or the library files is not in the places where you have specified. (MinGW compiler library folder or somewhere else on your hard drive).

Sometimes, particularly with things like Qt4 and Java, you may need to setup Environmental Variables under Advanced Properties in Computer; this is for in folders other than the MinGW library folder.
[size="5"]My Twitter

[size="2"]I do not care for reputation, merely to help fellow users.
A quick search on Google (SetDIBitsToDevice) revealed that you need to link with libgdi32.a (assuming MinGW). Under Build Options - Linker Settings - Link Libraries, add gdi32.

A quick search on Google (SetDIBitsToDevice) revealed that you need to link with libgdi32.a (assuming MinGW). Under Build Options - Linker Settings - Link Libraries, add gdi32.


Thank you SO much!
Working now!


What is a general rule of thumb process when adding a new library to a project?
It seems that no two libraries share exactly the same steps...
Rule of thumb: Include as few headers as possible, and link as few libraries as possible :wink:

As mentioned, most "undefined reference to SomeFunction@XX" are linker errors (the value XX indicates how many bytes of parameters it expects), and if you do not know which library it is defined within, you will just have to search (Google is your friend) or look in the source. Chances are, you are not the first to ask this question, or it will be documentated somewhere online, as the aforementioned function were on MSDN.

When you want to use a new library, you have usually read an article/tutorial about it, so you will know what functions/classes to use, which basic headers to include and which libraries to link with. The latter is only an option when someone have been so kind as to compile them for you - otherwise this you will also have to do yourself (can be a bit tricky if you also have to guess the compiler and linker parameters).
Now, whether you have read about its usage or not, it is always a good thing to get an overview of the library's general structure, since no two libraries are the same (as you have discovered). This will also give you an understanding of its usage and a clue as to how it works internally (can be useful when strange errors start to pop up). Just a quick look through the API Reference (Doxygen) or similar will usually do (heck, even scanning the main "include" directory reveils a lot about its structure if the headers are properly named).

This topic is closed to new replies.

Advertisement