public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Proglem making a lib for JNI
@ 2011-06-06  5:22 Robert M7654
  2011-06-06 21:41 ` kevin diggs
  0 siblings, 1 reply; 4+ messages in thread
From: Robert M7654 @ 2011-06-06  5:22 UTC (permalink / raw)
  To: gcc-help


Hi all,
I have a complicated question reguarding using GCC to compile my project.
Due to the fact that it is complicated and there are a number of diffrent
tools invovled I am not sure exactly what the problem is so I am not sure if
this is the correct forum to post in. I am hoping someone here can point me
in the right direction.


My project currently has two parts.
A backend, which I compile into a .lib file, and then a frontend which uses
this .lib file. (In fact I have a number of diffrent frontends)

This all works fine. Now I want to create a Java program which uses the
backend. I have done lots of research into JNI and created a few test
projects which work.

So what I need to do is make the .lib file into something which can be run
by java.

Firstly I am not sure the lib file is actually a lib file. I create it as
follows:

	g++ -c SM_Backend.cpp -o SM_Backend.obj -fPIC -shared

	...(More lines like above for each cpp)...
	ar cq SM_Backend.lib /SM_Backend.obj
	...(More lines like above for each obj)...


This gives me a lib file. 
Now I can goto a second project and using the following commands make an
.exe:
	g++ -s test.cpp -o test.exe -Wl,../smbackend/$(CFG)/SM_Backend.lib -pthread
-ldl


(Note, I am on ubuntu linux 64bit and I know I shouldn't give exe's a .exe
extenstion)

test.cpp has a main function which uses the library. This all works fine,
and importantly if I now delete SM_Backend.lib then test.exe still works. I
assume because al the functions in the lib have been placed into test.exe.

I have this working perfectly exactly how I want it. I now need to extend it
to get JNI's working.
to use JNI I need to add some special JNI only functions. I compile them
into javaapi.obj as follows:

	g++ -o javaapi.obj -I/usr/lib/jvm/java-6-openjdk/include -O0 -g3 -Wall -c
-fmessage-length=0 autogenjavaapi/cppcode/javaapi001.cpp $(CXXFLAGS)


I then copy my SM_Backend.lib to SM_BackendJAVA.lib and add them on:

	cp SM_Backend.lib SM_BackendJAVA.lib

	ar cq SM_BackendJAVA.lib javaapi.obj

From what I understand the produced SM_BackendJAVA.lib is an unlinked
library file. I believe it needs to be linked in order to be used by the
JVM. It also has to follow a naming convnetion for ld to find it. With this
as the aim I create libjavaapi.so as follows:

	g++ -o libjavaapi.so -Wl,$(CFG)/SM_BackendJAVA.lib -pthread -ldl -shared
-fPIC


This is the library file that the JVM will use. I have setup LD_LIBRARY_PATH
to include it and built a java program that should use it, when I run this
java progrma I get the following error:

Exception in thread "main" java.lang.UnsatisfiedLinkError:
com.metcarob.mys.javaapi.SM_Backend.constructor(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String
;ZLjava/lang/String;Z)V
	at com.metcarob.mys.javaapi.SM_Backend.constructor(Native Method)
	at com.metcarob.mys.javaapi.SM_Backend.<init>(SM_Backend.java:6)
	at mainAPP.main(mainAPP.java:18)

So
com.metcarob.mys.javaapi.SM_Backend.constructor(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;ZLjava/lang/String;Z)V
hasn't been found.

The source for the javaapi has the following function:
JNIEXPORT void JNICALL Java_com_metcarob_mys_javaapi_SM_1Backend_constructor
  (JNIEnv *env, jobject jobj, jstring p_jFileName, jstring p_jUserName,
jstring p_jPassword, jboolean p_jCreate, jstring p_jnewPass, jboolean
p_jdebug) {
  	printf("HELLO sda\n");
  	return;
  };

I have checked the naming rules in the JNI documentation and it is correct.
(The header was generated by javah anyway)

I think there is a problem with the way I created libjavaapi.so which is why
I am posting here. 

The file sizes of the .lib and the .so are as follows:
-rwxr-xr-x 1 robert robert    7557 2011-06-05 16:47 libjavaapi.so
-rw-r--r-- 1 robert robert 2477432 2011-06-05 16:47 SM_BackendJAVA.lib

as you can see the .so is a lot smaller than the lib file. I don't
understand why. It is simply the .lib file but now linked, how come it has
shrunk?
There must be something wrong with its creation command:
	g++ -o libjavaapi.so -Wl,$(CFG)/SM_BackendJAVA.lib -pthread -ldl -shared
-fPIC


Does anyone know where I am going wrong?
Is there a way to check what functions are in libjavaapi.so?

Thanks for your help
Robert


-- 
View this message in context: http://old.nabble.com/Proglem-making-a-lib-for-JNI-tp31777880p31777880.html
Sent from the gcc - Help mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Proglem making a lib for JNI
  2011-06-06  5:22 Proglem making a lib for JNI Robert M7654
@ 2011-06-06 21:41 ` kevin diggs
  2011-06-06 23:18   ` Jonathan Wakely
  0 siblings, 1 reply; 4+ messages in thread
From: kevin diggs @ 2011-06-06 21:41 UTC (permalink / raw)
  To: Robert M7654; +Cc: gcc-help

Hi,

On Sun, Jun 5, 2011 at 11:03 AM, Robert M7654 <rmetcalf9@googlemail.com> wrote:
>
>
> Firstly I am not sure the lib file is actually a lib file. I create it as
> follows:
>
>        g++ -c SM_Backend.cpp -o SM_Backend.obj -fPIC -shared
>
>        ...(More lines like above for each cpp)...
>        ar cq SM_Backend.lib /SM_Backend.obj
>        ...(More lines like above for each obj)...
>
>
I am not sure what -shared does when used with -c?

I *think* you want something like:

g++ -c -fPIC <blahx.cpp> <blahy.cpp> ...
g++ -shared -oloibSM_Backend.so blahx.o blahy.o ...

kevin

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Proglem making a lib for JNI
  2011-06-06 21:41 ` kevin diggs
@ 2011-06-06 23:18   ` Jonathan Wakely
  2011-06-07 18:39     ` Robert M7654
  0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Wakely @ 2011-06-06 23:18 UTC (permalink / raw)
  To: kevin diggs; +Cc: Robert M7654, gcc-help

On 6 June 2011 22:02, kevin diggs wrote:
>
> I *think* you want something like:
>
> g++ -c -fPIC <blahx.cpp> <blahy.cpp> ...
> g++ -shared -oloibSM_Backend.so blahx.o blahy.o ...

You should use -fPIC on the second command too, the docs for -shared say:
For predictable results, you must also specify the same set of options
that were used to generate code (-fpic, -fPIC, or model suboptions)
when you specify this option.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Proglem making a lib for JNI
  2011-06-06 23:18   ` Jonathan Wakely
@ 2011-06-07 18:39     ` Robert M7654
  0 siblings, 0 replies; 4+ messages in thread
From: Robert M7654 @ 2011-06-07 18:39 UTC (permalink / raw)
  To: gcc-help


Hi,
Thanks guys I think that was the solution
I used the same object files, just compiled it into a lib specially for JNI
as follows:

	$(CXX) -o $(CFG)/libjavaapi.so -O0 -g3 -Wall -fmessage-length=0 $(ALLOBJS)
$(CFG)/javaapi.obj -fPIC -shared -rdynamic

Thanks for the help
Robert


Jonathan Wakely-4 wrote:
> 
> On 6 June 2011 22:02, kevin diggs wrote:
>>
>> I *think* you want something like:
>>
>> g++ -c -fPIC <blahx.cpp> <blahy.cpp> ...
>> g++ -shared -oloibSM_Backend.so blahx.o blahy.o ...
> 
> You should use -fPIC on the second command too, the docs for -shared say:
> For predictable results, you must also specify the same set of options
> that were used to generate code (-fpic, -fPIC, or model suboptions)
> when you specify this option.
> 
> 

-- 
View this message in context: http://old.nabble.com/Proglem-making-a-lib-for-JNI-tp31777880p31794201.html
Sent from the gcc - Help mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-06-07 17:57 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-06  5:22 Proglem making a lib for JNI Robert M7654
2011-06-06 21:41 ` kevin diggs
2011-06-06 23:18   ` Jonathan Wakely
2011-06-07 18:39     ` Robert M7654

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).