Skip site navigation (1)Skip section navigation (2)
Date:      Sat,  1 Jan 2000 10:21:28 -0500 (EST)
From:      "Andrew B. Sudell" <asudell@acm.org>
To:        Keith Wong <keith@1connect.com>
Cc:        freebsd-java@freeBSD.ORG
Subject:   java JNI compile problems
Message-ID:  <14446.5474.172635.556466@vega.sudell.org>
In-Reply-To: <386D454B.694B5093@1connect.com>
References:  <386D454B.694B5093@1connect.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Keith Wong writes:
 > Hi All,
 > I want to use the java JNI to integrated with C.  And, i tried to follow
 > the example at the java.sun's website.  then I get the problem when I
 > try to compile the shared the library using gcc -g, then i get the
 > error.  i don't know is the -g parameter that i used it's right or not.
 > the error i got are:
 > /usr/lib/crt1.o: In function `_start':
 > /usr/lib/crt1.o(.text+0x69): undefined reference to `main'
 > 
 > I try the same step at Win98 with Visual C++ and it worked with no
 > problems.
 > May be I need the right parameter.  Is the JNI work at Freebsd? Thanks
 > for the help!!
 > Here are the source.
 > 

Keith:

The issue is not so much "does JNI work on FreeBSD" as how to build
shared libraries on FreeBSD (and other Unixes).  On Win 98, you had to 
tell the compiler to build a DLL and not an EXE.  (Forgive me, if I
don't recall the exact syntax for that -- it's been a while since I've 
lived in that world).  You need to do the equitist thing on FreeBSD
(i.e. tell the compiler/linker to build a .so and not a executable).

The first sign of what is happening is that the linker is linking in
the C runtime (crt1), whose job is to start up an executable and call
main().  You don't want your shared library to call main nor have
one.  Someone else (the jvm in this case) will do that before loading
the library.

To build a shared library ou need to do two things.

First, you need the compiler to generate "position independent code".
This is so that if two processes link the same so at runtime into
different addresses, the code can be correct for each process.  You'll 
want to add -fpic or -fPIC to the options you're passing the
compiler.  For small libraries -fpic should do.  For the exact
difference, see cc(1).

Second, you need to tell the linker to produce a shared object instead 
of an executable when it links the object(s).  Basically, the linker
needs to do several things.  It should not link in the C runtime.  It 
should build several extra tables in the library to support dynamic
linking, such as an exported symbol table.  For all the gory details,
see the ELF spec. There's one on the net, though I don't recall
where.  You do this by supplying the -shared argument to ld.  See
ld(1) for details.  If need be (only linking one source file, like
your example) you can have the compiler pass this flag to the linker,
by passing -shared to the compiler as well.

Something like

gcc -shared -fpic -o libhello.so ...

should work in your case.

The story above is valid for most (if not all) Unixen that support
shared objects, though the exact linker/compiler flags tend to vary.

Drew

-- 
        Drew Sudell     asudell@op.net      http://www.op.net/~asudell


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14446.5474.172635.556466>