Tim,

I was able to wrangle a fresh install of the gnu toolchain from our sys admin and was able to build JNA successfully -- it appears that the GNU linker is required for a successful build. If you're interested I could grab the latest release tag and send you the built jar (I just grabbed the latest trunk from svn) as this one should work on Sparc/Solaris8 and up since Sun guarantees binary forward compatibility.

Thanks for your help.

Corey

On Tue, Aug 5, 2008 at 11:57 AM, Timothy Wall <twal...@dev.java.net> wrote: Keep in mind that you should be able to swap in a local build of gnu ld if you can't get an official admin installation.

If a clean build doesn't fix the relocation errors, then you probably do have a compiler + linker incompatibility.

On Aug 1, 2008, at 7:23 PM, Corey Puffalt wrote:

Thanks again...

On Fri, Aug 1, 2008 at 5:14 PM, Timothy Wall <twal...@dev.java.net> wrote:

On Aug 1, 2008, at 6:01 PM, Corey Puffalt wrote:

Now the compile is erroring with the following output:

$ make gcc -W -Wall -Wno-unused -Wno-parentheses -fPIC -fno-omit-frame- pointer -fno-strict-aliasing -D_REENTRANT -DHAVE_PROTECTION - DFFI_MMAP_EXEC_WRIT -I"/include" -I"/include/solaris" -I"../build/ native" -I../build/native/libffi/include -DVERSION='"3.0.4"' - DCHECKSUM='"892beacd437514d23ed9b1cefeb2ead6"' -c dispatch.c -o ../ build/native/dispatch.o dispatch.c:69:17: jni.h: No such file or directory dispatch.c:71:18: jawt.h: No such file or directory dispatch.c:72:21: jawt_md.h: No such file or directory In file included from dispatch.c:74: dispatch.h:17:34: com_sun_jna_Function.h: No such file or directory

You're missing a "-I" flag indicating where the JDK headers are located; from the above output, it looks like JAVA_HOME is not set (thus the "-I/include" and "-I/include/solaris"). After that, it appears that the JNI headers (com_sun_jna_*.h) have not been generated -- I think there's an explicit ant target ("javah") to do so, and make sure the compiler can find them.

There should probably be a check in the Makefile to ensure that JAVA_HOME is set.

Thanks again...in my travels down the rabbit hole now I'm getting the following:

3$ make /progs/osver/bin/gcc -o ../build/native/libjnidispatch.so -shared - static-libgcc ../build/native/dispatch.o ../build/native/ callback.o ../build/native/libffi/.libs/libffi_convenience.a Text relocation remains referenced against symbol offset in file <unknown> 0x6c8 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) <unknown> 0x6cc ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) <unknown> 0x6d0 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) <unknown> 0x6d4 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) <unknown> 0x6d8 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) <unknown> 0x6dc ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) <unknown> 0x6e0 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) <unknown> 0x6e4 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) <unknown> 0x6e8 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) <unknown> 0x6ec ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) [..and a whole bunch more..] ffi_call_v8 0xc34 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) ffi_closure_v8 0xc70 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) ffi_closure_v8 0xc74 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) ffi_closure_sparc_inner_v8 0xd4 ../build/native/ libffi/.libs/libffi_convenience.a(v8.o) memmove 0xa80 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) memmove 0xad4 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) ffi_v9_layout_struct 0xa28 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) ffi_v9_layout_struct 0x1250 ../build/native/ libffi/.libs/libffi_convenience.a(ffi.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make: *** [../build/native/libjnidispatch.so] Error 1

Googling on this error seems to indicate that using the GNU linker instead of the Solaris one might resolve this problem. That or I've screwed something else up. I don't have access to the GNU binutils currently so that will have to wait until next week.

Sorry for spamming the list so much but I appreciate your help as I flounder through this.