From owner-freebsd-java Mon Feb 2 20:53:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA22581 for java-outgoing; Mon, 2 Feb 1998 20:53:39 -0800 (PST) (envelope-from owner-freebsd-java@FreeBSD.ORG) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA22574 for ; Mon, 2 Feb 1998 20:53:37 -0800 (PST) (envelope-from iang@systemics.com) Received: from hayek.guvnet (noddy [192.168.1.5]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id HAA12520; Tue, 3 Feb 1998 07:35:56 +0100 (MET) Message-ID: <34D6A37E.29B3C1AE@systemics.com> Date: Tue, 03 Feb 1998 04:56:30 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-971022-SNAP i386) MIME-Version: 1.0 To: freebsd-java@FreeBSD.ORG Subject: Re: jdk115 JNI requires ELF, gcc makes a.out References: <199802021801.MAA06681@damon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe java" Damon Permezel wrote: > I am certainly interested in any counter examples. I'll try :-) I'm back on it now, and I've written a test class which has the benefit of only involving 400 odd lines of Java code (Cryptix will soon rival the JDK :-). I'm now seeing useful debugging, and I get this: cannot stat "/usr/local/apps/java/java/bin/../lib/i386/green_threads//home/iang/src/helplets/current/native/build/x86-freebsd/libBlowfish.so" : No such file or directory (/home/iang/src/helplets/current/native/build/x86-freebsd/libBlowfish.so) java.lang.UnsatisfiedLinkError: /home/iang/src/helplets/current/native/build/x86-freebsd/libBlowfish.so ... from code which effectively does this: System.load("/home/iang/src/helplets/current/native/build/x86-freebsd/libBlowfish.so"); (sorry about the long names...). It is insisting on turning the absolute pathname into one relative to /usr/local/apps/java/java/bin/../lib/i386/green_threads/ Now, I can fix this by setting LD_LIBRARYPATH to the current dir and using a relative path: $ LD_LIBRARY_PATH=$PWD java Blowfish.BlowfishNative build/x86-freebsd/libBlowfish.so BlowNat: load: build/x86-freebsd/libBlowfish.so BlowNat: lib loaded successfully. BlowNat: Loaded. BlowNat: FAILED: java.lang.UnsatisfiedLinkError: getLibMajorVersion Which gets us nicely up to (my) next bug. However, that is the relative case, not the absolute case, the absolute still fails: $ LD_LIBRARY_PATH=$PWD java Blowfish.BlowfishNative $PWD/build/x86-freebsd/libBlowfish.so BlowNat: load: /home/iang/src/helplets/current/native/build/x86-freebsd/libBlowfish.so cannot stat "/home/iang/src/helplets/current/native//home/iang/src/helplets/current/native/build/x86-freebsd/libBlowfish.so" : No such file or directory (/home/iang/src/helplets/current/native/build/x86-freebsd/libBlowfish.so) java.lang.UnsatisfiedLinkError: /home/iang/src/helplets/current/native/build/x86-freebsd/libBlowfish.so ... It's now using the LD_LIBRARYPATH as the root. The doco for System.load implies only "complete" pathnames should be used: ===========8<========= load public synchronized void load(String filename) Loads the specified filename as a dynamic library. The filename argument must be a complete pathname. From java_g it will automagically insert "_g" before the ".so" (for example Runtime.getRuntime().load("/home/avh/lib/libX11.so");). ===========8<========= Perhaps I'd better throw some questions in: * is "complete" synonymous with absolute? * is this a bug, or a misinterpretation? * should I be using System.loadLibrary? * can I use absolute, relative, or what? * ... Note that at this stage I can survive, as a relative solution is fine. But I'd like to know what the end verdict is, for the doco. Thanks for your patience. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com