You can recompile OpenIL on your own, it''s open source after all.

quote:

---

Original post by guppy
if you can use .lib files (I higly doubt it, if you can) how do you tell mingw to link to them?

---

If you have a reasonably recent version of GCC/MinGW (probably around 2.95.3 or higher) then you can use MS .lib files.

quote:

---

(the '-l(libname)' switch always searches for 'lib(libname).a')

---

The easy way is to simply rename devil.lib (or whatever) to libdevil.a and put it in a place where ld will find it and then use -ldevil when executing the linker. ld will figure out that it's an MS lib file and not a real .a archive, and do the right thing.

The other solution is to give the full path to the lib file to ld when you're linking. Something like:

ld YOUR_OPTIONS_AND_STUFF_HERE C:\Somewhere\devil.lib

It works the same way if you're using dllwrap (or similar) to do the linking, since it executes ld with (some of) the options you give it.

[edited by - Dactylos on June 16, 2002 6:59:27 PM]

quote:

---

Original post by guppy
After some time I realised that there were no .a files - so using pexports & dlltool I made some new ones. Now the compiler is happy, but the linker gives me the following error:

"e:\dev-c++\misc_tests\deviltest.o(.text+0xc):deviltest.cpp: undefined reference to `_imp__ilInit'"

---

You most likely didn't specify the exports correctly. You can use nm on the dll and run the output through grep and a simple sed script that strips away all the junk to generate a .def file specifying what to export in the .a you generate. Look at the mingw site, I think they have a document somewhere explaining how to do it (or if you know how grep, sed and .def files work it's fairly easy to figure it out by yourself).

If this wasn't your problem, then I don't know. Perhaps it's easiest to just rename the lib as described in my post above, or recompile the whole thing by yourself...

[edited by - Dactylos on June 16, 2002 7:14:52 PM]

Thanks for the tip Dactylos ill try it later, would be nice if I did not have to re-create a .a file every time

I finaly got it working (offcourse I didn''t see your post until after ) it seems I forgot to use ''ranlib'' on my .a files before using them... (It doesn''t seem to change the file a all - but after using it the file works... :$ )

ill post procedure in this thread late (if any ones cares), but first i need to see if Dactylos''s method will work - and then some sleep

/Please excuse my bad spelling - My native language is binary not english
|Visit me
\Take my advice - I don''''t use it...

quote:

---

Original post by guppy
It doesn''t seem to change the file a all - but after using it the file works... :$

---

RANLIB(1)                        GNU Development Tools                        RANLIB(1)NAME       ranlib - generate index to archive.DESCRIPTION       ranlib  generates  an  index  to the contents of an archive and stores it in the       archive.  The index lists each symbol defined by a member of an archive that  is       a relocatable object file.

Normally if you create a ''.a'' file with ar with the -s switch it will do this on its own. However, you''re creating ''.a'' files in another fashion.

Guppy,

I''d be really interested in getting those .a files. Do you think you can upload them somewhere so that all of us Dev-C++ users can get them?

(Perhaps you can even contact the DevIL developers and see if they can add the files to their site).

quote:

---

Erunama wrote:
Guppy,

I'd be really interested in getting those .a files. Do you think you can upload them somewhere so that all of us Dev-C++ users can get them?

(Perhaps you can even contact the DevIL developers and see if they can add the files to their site).

---

well you (or any one else who is interestet for that matter) can grab the files the files in the programming section of my site :

http://decoder.dk/prog/download/

there is also an explanation of how to use them.

[edit]
Almost forgot - if you plan to use DevIL for OpenGL just should thake note of the fact that despite that the tutorials name all openGL related calls as ilutOgl it is actualy ilutGL.. guess they just haven't updated the dokumentation yet...
but hey who can blame them - coding IS a lot more fun!
[/edit]

/Please excuse my bad spelling - My native language is binary not english
|Visit me
\Take my advice - I don't use it...

[edited by - guppy on June 17, 2002 3:29:12 PM]
[edit]
just changed the link to match my new site structure
just in case the forum search ever gets to work again and somebody finds this post
[/edit]

[edited by - guppy on January 6, 2003 12:08:16 AM]

Thanks a million, Guppy.

I got DevIL to work with the NeHeGL II basecode (loaded the font bitmap usil DevIL instead of the aux function). I only got it to work, however, with ilutGLLoadImage, which automatically loads an image to a GL texture and deletes all of the unnecessary local stuff when its done.

Once I got that to work, I wanted to load an image the regular way, because later on that all-inclusive function may hold keep me boxed in (like, I don''t think you can do mip-maps and stuff with that). But when I changed my code around, it compiles fine, but I get a run-time error (Eru3d has cause an error in ERU3D.EXE), and the resolution stays at 640x480.

Here is the image handling code (I know the problem has to be here, since this is the only thing I changed):



And help would be appreciated.

you never store the id you get from ilutGLBindTexImage, try somthing like this...
texture[0].texId = ilutGLBindTexImage();

offcourse depending on how your code looks

quote:

---

(like, I don't think you can do mip-maps and stuff with that).

---

well at least they claim that you can

have a look here:
http://openil.sourceforge.net/tuts/tut_10/index.htm

also I'd check if the file was loaded sucessfully before generating textures, but thats just me

hope it helps...

/Please excuse my bad spelling - My native language is binary not english
|Visit me
\Take my advice - I don''t use it...

[edited by - guppy on June 17, 2002 5:43:54 PM]

Well, I did find one mistake. I had ilutGLBindTexImage in there, but I really wanted to use ilutGLTexImage because I already generated and bound a texture (whereas BindTexImage does that for you).

I was thinking the right way, though, because ilutGLTexImage returns a boolean value. The code does still does not work. Here is the updated version: