DevIL on Mac OS X Tiger

Started by numberR, May 05, 2005, 05:54:28

Previous topic - Next topic


hey guys.

i think i made some progress. i found that has following code at line number 586:

"IL", "IL"}, IL.class.getClassLoader());

i changed the second "IL" to "libIL.dylib" and created lwjgl_devil.jar. then it seems like now it's looking for libIL.dylib instead of IL, but i get following error:

Initial mode: 1024 x 768 x 32 @70Hz
Removed 0 duplicate displaymodes
getPathFromClassLoader: searching for: IL
getPathFromClassLoader: searching for: lwjgl
Found 2 devil paths
Testing 'libIL.dylib'
Found devil at 'libIL.dylib'
org.lwjgl.LWJGLException: Missing driver symbols
       at org.lwjgl.devil.ILU.initNativeStubs(Native Method)
       at org.lwjgl.devil.IL.create(

i enabled some of debug messages so it might help someone. now the question i have is what "Missing driver symbols" means. does this trick make any of you guys feel like now devil would work with dylibs?

by the way, nice job on lwjgl-0.97 :)


how did you get the dylib ?

Unlike any of the other platforms, Mac only loads IL and not ILU and ILUT because IL is one big library that loads all methods...

So you might need to remove the initialization of libILU.dylib and libILUT.dylib from the IL.create method, unless you they're embedded in libIL.dylib ?

i got libIL.dylib, libILU.dylib, libILUT.dylib and all other stuff from the link above. that's the one seems to be recommended on DevIL site.

Unlike any of the other platforms, Mac only loads IL and not ILU and ILUT because IL is one big library that loads all methods...

oh i see. i'll try to look at that... thanks


finally i got it to be working. as Matzon notified, it was exactly why i did not work.
i commented out where it checks if platform is mac os x and now it works fine with dylibs.
indeed i don't have devil framework installed.
there is not much change to java source code,
only, and with little of changes.
so the conclusion is that there is not much difference between Linux and Mac OS X except for Linux uses *.so and Mac OS X uses *.dylib.

could we expect this to be included in future release?


YES! - thanks for working out the kinks, I'll look into it this monday (when I am near a mac again). Great work!


I have comitted a version to cvs that uses .dylib instead.
However I am crashing on calling ilutInit in native code. I really don't have a clue as to what is going on.

If I comment the call to ilutInit in ILUT.create out, BasicTest runs fine... *ponder*. It would be of great help if you could help me debug this problem. It might involve compiling devil from cvs and adding debug code to it.

looking at the ilutInit file (
I can only guess at the issue being something with opengl. Because ilInit has been called at that point in time.

I will look at this as soon as I get some time, but will probably take a day or two.


there is yet another problem needs to be solved...

first, i'd like to make sure how i confirmed that devil worked with dylibs.

get this file and run "Devil Libraries.mpkg" inside the file.
this installs all of libIL.dylib, libILU.dylib, libILUT.dylib, libpng and all that to /usr/local/lib.

create lwjgl-devil.jar from cvs.
i confirmed that what Matzon committed to cvs worked fine on my machine, at least.

run lwjgl application that uses devil.

the problem i found is that, lwjgl can load libIL.dylib from java.library.path so you actually don't have to install "Devil Libraries.mpkg", however, libraries like libpng and libjpeg are needed by libIL.dylib and in that case, libIL.dylib does not look for java.library.path but /use/local/lib.
i thought it could be solved if we compile libIL.dylib staticly with libpng and all that, but i haven't tried it yet.

i'll look for solution.


ah, i think i got libIL.dylib, libILU.dylib and libILUT.dylib working without libpng and all other dylibs that DevIL uses at run time.
i just compiled libIL.dylib, libILU.dylib and libILUT.dylib with libpng.a instead of libpng.dylib and so on,
so now it does not need to look for libpng.dylib.
i dropped mng support in order to compile libIL.dylib,
but i think it's not that big deal for video game...

so forget about my previous post and refer steps below:

get LWJGL-0.97 and setup them as you usualy do, such as copying *.jar and *jnilib to your java.library.path.

get this file, uncompress it and copy libIL.dylib, libILU.dylib and libILUT.dylib to your java.library.path (it does not have to be /usr/local/lib anymore!).
overwrite ones come with LWJGL.

compile lwjgl-devil.jar from cvs, and place it to your java.library.path.

run LWJGL application.

it should work.
i guess distributing my libIL.dylib, libILU.dylib and libILUT.dylib does not violate GPL or licenses that libpng and other libraries use, does it?


Very good question, I will contact the author of devil, and see if he has an idea. Since the dylibs are linked to GPL code, they may infact themselves have "become" GPL, which means that lwjgl cannot link to them, not even dynamically like we do with DevIL ordinarily and OpenAL.

Do you still have to comment out ilutInit ?


I tried to add a --enable-static option to building devil, but that only results in a static devil library, and not what we want, a dynamic devil library, with statically linked support libraries :(

I then manually forced 'ld' to only locate the static libraries, by renaming the dynmic support libraries in /usr/lib (linux) - and it actually worked! (though libjpeg didn't want to play along, so had to disable that in my compile). But since renaming /usr/lib files is an invitation for errors, I would like to locate a switch to autoconf that makes it compile the support libraries statically - anyone out there?


what i did to create a dynamic devil library that statically linked with support libraries was, edit the final gcc line.

for example, ./ & ./configure & make creates normal libIL.dylib that dynamically linked with support libraries. this is not what we want. so i took the last gcc line used to create libIL.dylib, and edit where it passes /use/local/lib/libpng.dylib to /usr/local/lib/libpng.a. this way, you can create a dynamic devil library that statically linked with support libraries. i piped output of make by doing "make > log.txt".

yea, this is simply not smart.
i would be happy if someone can point out better way to do this.


hmm, cant get that working in linux - nor can I under mac (I am having issues compiling devil - have to disable opengl).
Can you confirm that your trick works with latest lwjgl from cvs? - if so I will just repackage that.


yea, i compiled lwjgl_devil.jar and liblwjgl-devil.jnilib from cvs and it worked with my previously posted libIL.dylib.
have you deleted devil framework? (sitting in /Library/Frameworks)
it should not bother, but i'm just curious...
i'll make for Linux after my exams, hopefully tomorrow night.

for mac os x, devil compilation fails by OpenGL errors, but adding "-framework OpenGL" to last gcc line seems to work, as devil forum says.


hmm, now we seem to stuck.
does which OpenGL interface to use matter? or does ILUT work when you use it with C/C++?
these are the only things that i can think of right now...

if we cannot get this problem solved, we might need to go back to DevIL framework.
otherwise, one cannot use ILUT with lwjgl, which is not good :(


i kinda found why libILUT.dylib hates us so much.
i tried to use DevIL in C++, and i took gltest.c comes with DevIL.
i noticed gltest.c does not call neither of iluInit() or ilutInit() event it uses ILU and ILUT.
i compiled gltest.c and worked like charm.
i put iluInit() and gltest still worked fine.
but as soon as i put ilutInit(), gltest dumps error saying "Bus error", which is what we were getting when we use ILUT from Java.

so i conclude that this is DevIL issue on Mac OS X and not of LWJGL.
i don't know why, but it is ilutGLInit() in ilut_opengl.c that causes this problem.

temporary fix might be commenting out call to ilutInit() from ILUT.ilutInit() in org_lwjgl_devil_ILUT.c, when the system is Mac OS X.
in fact, i got BasicTest working with IL*.dylib if i commented out ilutInit() in ILUT.ilutInit().

what do you guys think?
wierd thing is that ilutInit is not event on DevIL documentation...