OpenIL/DevIL .lib/.dll problems

[Decrius]

Hello,

I tried to get DevIL (previously called OpenIL, an image library for OpenGL) running, without succes yet.

I downloaded the Win32 package, placed all the include file (.h) in "include/IL/" and the .lib files, .exp files and .dll files in the "lib/" directory. I even tried to put the .dll files in "windows/system32/". I include all the header files, and use Project -> Build options -> Linker -> Add to add all the .lib files.

I don't know where to place the .dll files, and what .exp files are. This is what I get when I want to initialize the image library:

Code

Project   : GLFW Application
Compiler  : GNU GCC Compiler (called directly)
Directory : G:\Documents and Settings\Taco\Bureaublad\Coding\C\GLFW\
--------------------------------------------------------------------------------
Switching to target: default
Linking executable: glfw.exe
.objs\main.o:main.cpp:(.text+0x5b8): undefined reference to `_imp__ilInit@0'
.objs\main.o:main.cpp:(.text+0x5bf): undefined reference to `_imp__iluInit@0'
.objs\main.o:main.cpp:(.text+0x5cd): undefined reference to `_imp__ilutRenderer@4'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)

I saw that the text "_imp__ilInit@0" etc, are in the library files. So whats wrong, .dll or .lib files? Or something else ^^,

Thank you very much,

Decrius

[MortenMacFly]

I saw that the text "_imp__ilInit@0" etc, are in the library files. So whats wrong, .dll or .lib files?

Libs are for *linking*, DLL's are (usually) for *run-time*. There is a way to link against DLL's, too but this is something special. So in your case it's a *linker* error. The linker complains that it cannot resolve external symbols that originate from the DevIL library (obviously - I don't know DevIL). So you are missing to link against one or more DevIL libraries.
To better analyse the compiler/linker process I suggest you enable "full logging" - see my sig.
Then re-post the error but I'm sure you can resolve it easily yourself by adding the appropriate lib to link against in the project/target options.
With regards, Morten.

[Decrius]

Thank you for the reply

I also tried another image library, which has only 1 .dll 1 .h and 1 .lib file.

Result:

Code

Project   : GLFW Application
Compiler  : GNU GCC Compiler (called directly)
Directory : G:\Documents and Settings\Taco\Bureaublad\Coding\C\GLFW\
--------------------------------------------------------------------------------
Switching to target: default
mingw32-g++.exe    -L"J:\Program Files\CodeBlocks\lib" -o glfw.exe .objs\main.o      -lglut32 -lglu32 -lopengl32 -lfreeimage   -lglfw -lopengl32 -lglu32 -luser32 -lkernel32 -lgdi32  -mwindows
/mingw/lib/crt2.o:crt1.c:(.text+0x16a): undefined reference to `__cpu_features_init'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)

Maybe I don't use the linker right?

FreeImage.lib (shouldn't it be .a?) is placed in the lib directory. Build -> Compiler Options -> Linker -> right text area is where I put this line:

-lfreeimage

Decrius

[MortenMacFly]

Code

/mingw/lib/crt2.o:crt1.c:(.text+0x16a): undefined reference to `__cpu_features_init'

This could be an outdated mingw version, a conflict in the compiler and Win32 API libraries (that usually ship with MinGW) or simply a wrong (incompatible) library. Did you overwrite / mix / extract manually some libs into your (a wrong) MinGW folder?

FreeImage.lib (shouldn't it be .a?) is placed in the lib directory. Build -> Compiler Options -> Linker -> right text area is where I put this line:

Yes, to be fully GCC compatible you better should use a freeimage library that has been built with MinGW, too. However, the MinGW compiler can hadle most *.lib libraries, too. You can use e.g. the DevPak plugin to download a "pure" MinGW version of freeimage. I believe the GnuWin32 project does offer a "native" variant, too.

In addition: Although the setup in correct in principle it's be better to do it this way:
In the projects build options select the "linker" tab. Add the library "freeimage.a" on the left side using the "add" button. Very perfect would be to just add "freeimage" there (no path, nothing else) and add the path to this lib in the linker directories.

With regards, Morten.

[Decrius]

I might have mixed libs yes, and its very outdated, can I just overwrite the old MinGW with a new one? Or is it really better if I use NBs? (Read other topic of me)

Thanks,

Decrius

[MortenMacFly]

I might have mixed libs yes, and its very outdated, can I just overwrite the old MinGW with a new one?

I will tell you, how I manage:
- I have a folder "D:\Devel\CodeBlocks" with the nightly (SVN) version of C::B.
- I have another folder with the compiler/linker executables -> D:\Devel\MinGW
To install the compiler I used (unpacked) the packages provided at MinGW.org but you can also use the installer that is provided there.
- I have another folder called "D:\Devel\DevPacks" which has a lot sub-folders (e.g. "GLFW", "GLUT", "wxWidgets" and so on...). Each of these sub-folders has at least an "include" and a "lib" folder itself. I mainly have downloaded DevPak's or compiled myself to achieve this.
Now let's say I want to develop an application that uses GLUI, then I setup a project as following:
- For the compiler: include directories: Add D:\Devel\DevPacks\GLUI\include and D:\Devel\DevPacks\GLUT\include (since GLUI is based on GLUT)
- For the linker: linker directories: D:\Devel\DevPacks\GLUI\lib, D:\Devel\DevPacks\GLUT\lib; libraries to link against (on the left part): "glut32" and "glui" (just "Add" and put e.g. "glui" in the textbox).
Notice that the libraries are actually called "libglui.a" and "libglut32.a" on my HDD. Anyway - C::B will take care of the prefix "lib", the extension ".a" (if required) and the command line switch "-l" for the linker.
And that's also the difference between "left and right" (from the other post of yours): The left part is only to provide the linker with additional libraries to link against. C::B will take care to compute the "right" command line switch. The "right" part is for *any* linker switch C::B just adds but doesn't modify at all, thus not only libs but also additional flags, defines, whatever...

I hope this helps. If not, please post a message with a zipped minimalistic project of your's that doesn't work.

With regards, Morten.

Ps.: I wonder what shall come out of this anyway... freeimage and glut/glfw is not an "easy stuff". Don't you think you should start at another more "hello world" like level and come back to something more difficult later?!

[Decrius]

Ps.: I wonder what shall come out of this anyway... freeimage and glut/glfw is not an "easy stuff". Don't you think you should start at another more "hello world" like level and come back to something more difficult later?!

I did that , been working with C for a year now, and OpenGL a half year. But only now I can't get it to work :S. I will reinstall everything again and make structured directories like you .

Thanks a lot, however, would be better if I first get CB NBs to work, and than I'll try that

Decrius

[Decrius]

I set it up like you set, woth the DevPacks. Works organized for me , thank you. And yes, from mingw 3.8.1 to 5.2.1 is much better, the libs are working .

Thanks for all!

Decrius

[tudumanu]

-ldevil -lilut -lilu
Put these on the linker to correct the :  [linker error] undefined reference to `_imp__ilInit@0' or [linker error] undefined reference to `_imp__iluInit@0'
don´t forget to install the library first ! on check for updates (for DEVC++) install DevIL...
the includes:
#include <IL/il.h>
#include <IL/ilu.h>
#include <IL/ilut.h>      //Used for loading the textures

Att
Tadeu Borges de Abreu Sampaio
Tudumanu