Skip to main content
gamedev.net
🔒 Locked

Problem with compiling shared libraries

Started by Khaos Dragon 7 replies 8.2k views
Original Post
Khaos Dragon
Khaos Dragon
I am using Java Native Interface to utilize native c++ code in my Java apps. I have gotten this to work perfectly fine on Windows XP with no problems. However, whenever I try to load my so file in my Linux jvm via System.LoadLibrary, I get a very strange cryptic error: Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/misha/JSocket/dist/libRLimitNative.so: /home/misha/JSocket/dist/libRLimitNative.so: invalid ELF header (Possible cause: endianness mismatch) I realize that the JVM is in big endian and that my x86 is in little endian... however the JVM does not seem to have issues resolving the endianness when I do this in windows xp. The way I compile my shared library in linux is: g++ -I/JAVA_HOME/include -I/JAVA_HOME/include/linux -shared RLimitNative.cpp -o libRLimitNative.so I don't get any compile time errors or warning doing this... just wondering is there is something about shared libraries in linux that I don't understand.
hydroo
hydroo
I don't really know if it matters in your case, but you should compile and link using -fPIC.

At least that's what I am told 8[


Thats what autotools pretty much do:
------------------------------------
compile --
gcc -DHAVE_CONFIG_H -I. -I.. -I. -g -O2 -MT OTF_inttypes.lo -MD -MP -MF .deps/OTF_inttypes.Tpo -c OTF_inttypes.c -fPIC -DPIC -o .libs/OTF_inttypes.o

and so forth

link --
gcc -shared .libs/OTF_CopyHandler.o .libs/OTF_File.o .libs/OTF_FileManager.o .libs/OTF_Filenames.o .libs/OTF_HandlerArray.o .libs/OTF_MasterControl.o .libs/OTF_Parse.o .libs/OTF_RBuffer.o .libs/OTF_Reader.o .libs/OTF_RStream.o .libs/OTF_WBuffer.o .libs/OTF_Writer.o .libs/OTF_WStream.o .libs/OTF_inttypes.o -Wl,-soname -Wl,libotf.so.0 -o .libs/libotf.so.0.0.0


Looks a bit scary due to the subdirectories.

[Edited by - hydroo on July 31, 2007 2:49:40 PM]
Khaos Dragon
Khaos Dragon
Quote:
Original post by hydroo
I don't really know if it matters in your case, but you should compile and link using -fPIC.

At least that's what I am told 8[


Thank you for the suggestion. I have heard this too in my random research (google) and have tried with both the -fPIC and -fpic options. Unfortunately..these don't seem to change anything.
Khaos Dragon
Khaos Dragon
Hmmm so if I were to use fPIC, I could not do it naively like the way I have been doing?

For reference, this is the way I have used fPIC and fpic.

g++ -I/..... -I/...../.... -shared -fPIC RLimitNative.h -o libRLimitNative.so

hydroo
hydroo
It should be fine. Except you are only only using a ".h" file ? Should be a .c(pp)-file right?
Khaos Dragon
Khaos Dragon
Does it need to be a cpp file? It works fine compiling a single .h in visual studio, but perhaps there is something gcc specific I don't know? The reason I use a .h is that there are literally 4 lines of code in this library I am compiling and since that is as complex as it will get, I didn't see a need to separate declarations and definitions.
Khaos Dragon
Khaos Dragon
I guess it does need to be a cpp file as it works now.
Does gcc not generate object files for files ending in .h?
hydroo
hydroo
Sure he does. I was just irritated, since usually one does not compile headers - they are shipped with the library. As for the compiler the ending does not matter.

So in the end: I don't know what's wrong
Khaos Dragon
Khaos Dragon
Quote:
Original post by hydroo
Sure he does. I was just irritated, since usually one does not compile headers - they are shipped with the library. As for the compiler the ending does not matter.

So in the end: I don't know what's wrong


I agree, but I made an exception in this case and it ended up biting me.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.