Newbie: devIL create problem

[solarforce]

Hello

I have tried to run a devIL test from the test pack (org.lwjgl.test.devil.BasicTest), but i have got this message:

org.lwjgl.LWJGLException: Could not load devil library.
   at org.lwjgl.devil.IL.nCreate(Native Method)
   at org.lwjgl.devil.IL.create(IL.java:599)
   at test.BasicTest.main(BasicTest.java:60)

(my platform is an ubuntu with j2re1.5 and j2sdk1.5, and the Gears example is running correctly)

bye
 Viktor

[Matzon]

most likely you have incompatibility issues with the libraries devil require. Do a ldd libil.so
We are trying to fix this, we need someone with some good make file experience, since we need to compile a dynamic version of devil, with its support libraries statically compiled into it.

[numberR]

http://unixforge.org/~numberr/data/devil_static_linux.zip
could you try this one?

just replace libIL.so, libILU.so and libILUT.so with the ones come with lwjgl-0.98 release.
i compiled libIL.so so that it would not require libpng, libttif and libjpeg.
BasicTest worked fine on FC4.

thing is that i can do this on Linux but on Mac OS X. difference is that dylib requires full path of where those dylibs will be located at. this makes it harder to make dylibs that would sit anywhere.

i looked at Ogre and they are using devil with frameworks. i also figured out that you can install user by user frameworks at ~/Frameworks, which is better than installing it in /Library/Frameworks i suppose.

Darwin expert needed!

[Matzon]

I was under the impression that devil didn't do frameworks anymore:
"The framework version will not be supported, it was just causing problem, now is deployed as a dynamic library stored in /usr/local"

numberR - is that a heavily modified build file or ?
We want to distribute a static build, but we need to be able to recreate it at any time.

What about the other support libs?

[solarforce]

http://unixforge.org/~numberr/data/devil_static_linux.zip
could you try this one?

just replace libIL.so, libILU.so and libILUT.so with the ones come with lwjgl-0.98 release.

thanks, its worked:))

but with this http://unixforge.org/~numberr/data/devil-20050526.zip (libIL.so)
the others come from the lwjgl-0.98 release.

when i was runnig with devil_static_linux.zip (libIL.so), i got a similar error message:(

[numberR]

Matzon,
as DevIL site says, i think framework is no longer developped. but that's what Ogre is using and maybe that's because of the issues we are having.

it is not heavily modified. i just took output of make command, and replaced '-lpng' or those statements with '/usr/lib/libpng.a'. DevIL seems to use libpng, libtiff, libmng and libjpeg but not other libraries. i disabled support for mng because libmng.a is, somehow, not provided for platforms that i know of. supports for other image formats are embedded in DevIL. i think it might be just a little change to configure script or something, but i have no idea what i need to do:(


solarforce,
thanks and glad it worked.
does 'devil_static_linux.zip' work if you create symbolic link called 'libIL.so.1' pointing to 'libIL.so', 'libILU.so.1' pointing to 'libILU.so' and 'libILUT.so.1' pointing to 'libILUT.so'?
because libILU.so and libILUT.so come with devil-20050526.zip are staticly linked to libIL.so, but i don't think i need to do that.

[rapand]

Hi

I have the exact same problem on a Dell GX270 that has to use software rendering to work. I run Debian and tried NeHes lwjgl tutorial Lesson06 out.

I just installed the 2 packages:
libdevil-dev
libdevil1c2
with version number 1.6.7-4.1

I made a similar simple work-around by copying the installed file :
cp /usr/lib/libIL.so.1.0.0 /<myhomedir>/lwjgl-linux-0.98/native/libIL.so

And then uninstall the 2 Debian packages libdevil-dev and libdevil1c2

All though not a nice workarround. It must be because of the LoadLibrary method cannot work with lwjgl 0.98 version of libIL.so (as someone wrote) in method "bool extil_Open(JNIEnv *env, jobjectArray ilPaths)" in lwjgl-linux-0.98/src/native/common/devil/extil.c cannot work with the original libAL.so file. I checked with eclipse and its debugger - It finds the right path for the native directory and the libAL.so file (ofcause else my work-around would not work!) So I guess its a DevIL problem.

The not so funny thing is that it works perfectly on my friends Fedora Core 4 laptop.