From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-12-26 23:24:12
|
Hi Don, I've succeeded in building ABCL in the NetBeans debugger and load AP5 with it as far as you were able to. Or at least, that's what it looks like. I'm able to consistently find myself with an "Out of memory: Java heap space" exception, so it looks like I'm able to reproduce. However, I'm not exactly sure where in the compilation process this error occurs: it might be in a compile phase or in a loader phase. Anyway: are you allocating huge integers, possibly many of them? I'm finding myself with the OOM in this line (in BigInteger.java:2021): newMag = new int[magLen + nInts]; Which suggests the bigInteger can't be allocated. I'm not able to break at that position under the offending circumstances yet though. The error occurs either during the compilation of treegen.lsp, the loading thereof or during compilation of generators.lsp. Any idea where I'm supposed to go look? Bye, Erik. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-12-27 00:02:38
|
On Sat, Dec 27, 2008 at 12:24 AM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > Hi Don, > > I've succeeded in building ABCL in the NetBeans debugger and load AP5 > with it as far as you were able to. Or at least, that's what it looks > like. > > I'm able to consistently find myself with an "Out of memory: Java heap > space" exception, so it looks like I'm able to reproduce. However, I'm > not exactly sure where in the compilation process this error occurs: > it might be in a compile phase or in a loader phase. Anyway: are you > allocating huge integers, possibly many of them? I'm finding myself > with the OOM in this line (in BigInteger.java:2021): > > newMag = new int[magLen + nInts]; > > Which suggests the bigInteger can't be allocated. I'm not able to > break at that position under the offending circumstances yet though. > > The error occurs either during the compilation of treegen.lsp, the > loading thereof or during compilation of generators.lsp. Any idea > where I'm supposed to go look? Replying to myself: the line mentioned is nested in a call to ASH. Since treegen contains only 1 call to ASH and generators doesn't contain ASH calls at all, I believe the problem is in treegen. Additionally, the problem is probably in *compiling* treegen, because I don't see a completed FASL file anywhere. I do see intermediate products which suggest compilation of TREETESTER did complete, however any subsequent form did not. That's consistent with the location of the ASH call because the next form is TREEGENERATOR which contains the call to ASH. However, if the compiler is still running and what it's doing: I have no idea yet. Why would the compiler be calling ASH, since the arguments don't seem to be constants? Bye, Erik. |
From: <don...@is...> - 2008-12-28 21:24:58
|
(Sorry, I was away from the net for a few days.) Erik Huelsmann writes: > > I'm able to consistently find myself with an "Out of memory: Java heap > > space" exception, so it looks like I'm able to reproduce. However, I'm > > not exactly sure where in the compilation process this error occurs: > > it might be in a compile phase or in a loader phase. Anyway: are you > > allocating huge integers, possibly many of them? I'm finding myself > > with the OOM in this line (in BigInteger.java:2021): My impression was that the error occurred inside compile-file. I do normally load the compiled file after compiling it, but that would normally be preceded by the message saying that we're loading. Now that I look, it does seem odd that the output looks like this: ... ; (DEFUN TREEDELETER ...) ; (DEFUN TREETESTER ...) ; (DEFUN TREEGENERATOR ...) ; Compilation unit finished ; The following functions were used but not defined: ; ARITY* ; GET-COMPARISONS-AND-CANONICALIZERS Debugger invoked on condition of type ERROR: Out of memory. whereas the source file contains ... (defun treedeleter (tuple tree compare-rels &aux subtree) ... (defun treetester (tuple tree compare-rels) ... (defun treegenerator (subsetflg vars rel &rest args &aux stored ... (defun fix-tree-equiv (rel temp) and many more functions. So something is going wrong before, perhaps even in reading the file. I suggest removing everything after (defun treetester ...) then putting (defun treegenerator ...) in a separate file, and after compiling and loading treegen (it would be real convenient to be able to save an image here!), try compiling the file containing treegenerator. |
From: Erik H. <eh...@gm...> - 2009-01-18 12:28:52
|
Hi Don, On Sun, Dec 28, 2008 at 10:24 PM, Don Cohen <don...@is...> wrote: > (Sorry, I was away from the net for a few days.) > Erik Huelsmann writes: > > > I'm able to consistently find myself with an "Out of memory: Java heap > > > space" exception, so it looks like I'm able to reproduce. However, I'm > > > not exactly sure where in the compilation process this error occurs: > > > it might be in a compile phase or in a loader phase. Anyway: are you > > > allocating huge integers, possibly many of them? I'm finding myself > > > with the OOM in this line (in BigInteger.java:2021): > > My impression was that the error occurred inside compile-file. > I do normally load the compiled file after compiling it, but that > would normally be preceded by the message saying that we're loading. > > Now that I look, it does seem odd that the output looks like this: > ... > ; (DEFUN TREEDELETER ...) > ; (DEFUN TREETESTER ...) > ; (DEFUN TREEGENERATOR ...) > > ; Compilation unit finished > ; The following functions were used but not defined: > ; ARITY* > ; GET-COMPARISONS-AND-CANONICALIZERS > > Debugger invoked on condition of type ERROR: > Out of memory. > > whereas the source file contains > ... > (defun treedeleter (tuple tree compare-rels &aux subtree) > ... > (defun treetester (tuple tree compare-rels) > ... > (defun treegenerator (subsetflg vars rel &rest args &aux stored > ... > (defun fix-tree-equiv (rel temp) > and many more functions. > So something is going wrong before, perhaps even in reading the file. Ok. I have some more outcomes (sorry for the slow pace): The file is being read correctly. The problem is in the handling of the compilation step of ASH: DERIVE-TYPE-ASH is doing some ASH operations of itself. One of the shift operations is trying to shift '1' by 2147483646 positions. It seems the BigInt can't accomodate that much space :-) Ville, you recently organised code related to the (when-args-integer ...) stuff. Can you comment on what that function is doing, possibly even finding where we're doing this extreme shift? I mean, it's not really usefull to calculate that number, right? Better to say (INTEGER 2 *) or something like it. I'll try to find out what the usefull bounds of INTEGER are for the compiler. Bye, Erik. |
From: Erik H. <eh...@gm...> - 2009-01-18 18:36:43
|
On Sun, Jan 18, 2009 at 1:28 PM, Erik Huelsmann <eh...@gm...> wrote: > Hi Don, > > On Sun, Dec 28, 2008 at 10:24 PM, Don Cohen > <don...@is...> wrote: >> (Sorry, I was away from the net for a few days.) >> Erik Huelsmann writes: >> > > I'm able to consistently find myself with an "Out of memory: Java heap >> > > space" exception, so it looks like I'm able to reproduce. However, I'm >> > > not exactly sure where in the compilation process this error occurs: >> > > it might be in a compile phase or in a loader phase. Anyway: are you >> > > allocating huge integers, possibly many of them? I'm finding myself >> > > with the OOM in this line (in BigInteger.java:2021): >> >> My impression was that the error occurred inside compile-file. >> I do normally load the compiled file after compiling it, but that >> would normally be preceded by the message saying that we're loading. >> >> Now that I look, it does seem odd that the output looks like this: >> ... >> ; (DEFUN TREEDELETER ...) >> ; (DEFUN TREETESTER ...) >> ; (DEFUN TREEGENERATOR ...) >> >> ; Compilation unit finished >> ; The following functions were used but not defined: >> ; ARITY* >> ; GET-COMPARISONS-AND-CANONICALIZERS >> >> Debugger invoked on condition of type ERROR: >> Out of memory. >> >> whereas the source file contains >> ... >> (defun treedeleter (tuple tree compare-rels &aux subtree) >> ... >> (defun treetester (tuple tree compare-rels) >> ... >> (defun treegenerator (subsetflg vars rel &rest args &aux stored >> ... >> (defun fix-tree-equiv (rel temp) >> and many more functions. >> So something is going wrong before, perhaps even in reading the file. > > Ok. I have some more outcomes (sorry for the slow pace): The file is > being read correctly. The problem is in the handling of the > compilation step of ASH: DERIVE-TYPE-ASH is doing some ASH operations > of itself. One of the shift operations is trying to shift '1' by > 2147483646 positions. It seems the BigInt can't accomodate that much > space :-) > > Ville, you recently organised code related to the (when-args-integer > ...) stuff. Can you comment on what that function is doing, possibly > even finding where we're doing this extreme shift? I mean, it's not > really usefull to calculate that number, right? Better to say (INTEGER > 2 *) or something like it. > > I'll try to find out what the usefull bounds of INTEGER are for the compiler. Well, this issue is now fixed in trunk/. I hope you have more success with AP5 now. Thanks for your report. I'm looking forward to any further reports if you have them! Bye, Erik. |
From: <don...@is...> - 2009-01-19 02:18:23
|
Erik Huelsmann writes: > Well, this issue is now fixed in trunk/. I hope you have more success > with AP5 now. > Thanks for your report. I'm looking forward to any further reports if > you have them! So far I'm having trouble building: $ svn co svn://common-lisp.net/project/armedbear/svn/trunk/abcl abcl ... $ cd abcl/ $ clisp [1]> (load "build-abcl.lisp") ;; Loading file build-abcl.lisp ... *** - ZEROP: NIL is not a number This turns out to be due to the fact that (ext:run-shell-command "uname | grep -i linux" :output nil) returns NIL. I change zerop in that line to null as a temporary measure. I wonder whether I could be the first to try to build with openjdk. Syntax error, annotations are only available if source level is 1.5 I add -5 to *javac-options* Now I get many warnings ending with ---------- 735 problems (735 warnings)Build failed. NIL I now try adding -nowarn to *javac-options* but that's not good enough: BUILD-ABCL[13]> (build-abcl:build-abcl :clean t :full t) ;; Loading file /tmp/abcl/customizations.lisp ... ;; Loaded file /tmp/abcl/customizations.lisp Platform: Linux JDK: /usr/ Java compiler: /usr/bin/javac Compiler options: -g -5 -nowarn Build failed. NIL BUILD-ABCL[14]> Any ideas? |
From: <don...@is...> - 2009-01-19 05:08:27
|
Don Cohen writes: > BUILD-ABCL[13]> (build-abcl:build-abcl :clean t :full t) > ;; Loading file /tmp/abcl/customizations.lisp ... > ;; Loaded file /tmp/abcl/customizations.lisp > Platform: Linux > JDK: /usr/ > Java compiler: /usr/bin/javac > Compiler options: -g -5 -nowarn > > Build failed. > NIL > BUILD-ABCL[14]> > > Any ideas? This is due to the javac that generates the errors returning -1. Again, for now I force java-compile-file to return t. Is there some spec for the return value of javac ? Perhaps you're just assuming the behavior you see in the sun version. I don't see a javac option for controlling it. It turns out that I'm running a cvs version of clisp that seems to be incorrectly returning nil from ext:run-shell-command - I've reported the problem. I'm now breaking format and returning from forms that contain failure messages followed by return-from. I seem to have built a working abcl this way. Now on to ap5... |
From: <don...@is...> - 2009-01-19 07:05:24
|
Don Cohen writes: > (ext:run-shell-command "uname | grep -i linux" :output nil) returns NIL. This turns out to be a recent change in clisp. I've asked how to write code conditionalized on clisp version. Next questions: Is there some existing code out of which I could conveniently build a function to return the recursive macroexpansion of a form (in an optional environment)? (lisp:defun mexpand-all (x &optional env) #+(or lucid clisp lispworks) (declare (ignore env)) (unless (eq 'lambda (car x)) (error "mexpand-all being used on a non-lambda expression")) #+symbolics ; returns (function ...) (cadr (si:macroexpand-all x :environment env)) #+ti (cadadr (si:macroexpand-all `(apply (function ,x) x) env)) #+allegro ;; ditto -- ALLEGRO also has excl::compiler-walk ;; -- It expands COMPILER-MACROs as well as ;; -- regular macros (cadr (clos::walk-form `(function ,x) env)) #+lucid (first (LWALKER::WALK-FORM (list x))) #+clisp (EXT:EXPAND-FORM x) ;; exported as of 2.31 #+lispworks (first (WALKER::WALK-FORM (list x))) #+aclpc (allegro::macroexpand-all x env) #abcl ;; *** what should I put here? ) Example - in clisp [1]> (ext:expand-form '(loop for i below n do (push x i))) (LET ((#:LIMIT-2907 N) (I 0)) (LET NIL (TAGBODY SYSTEM::BEGIN-LOOP (WHEN (>= I #:LIMIT-2907) (GO SYSTEM::END-LOOP)) (SETQ I (CONS X I)) (PSETQ I (+ I 1)) (GO SYSTEM::BEGIN-LOOP) SYSTEM::END-LOOP))) ; T Is there a way to find the function that accesses a slot of a defstruct, given the struct and slot names? Example: (defstruct (|Test-structure | (:conc-name "T-S-conc-")) qwerty uiop) (what-function-is-this '|Test-structure | 'querty) => |T-S-conc-QWERTY| |
From: Erik H. <eh...@gm...> - 2009-01-19 16:09:42
|
On Mon, Jan 19, 2009 at 2:44 AM, Don Cohen <don...@is...> wrote: > Erik Huelsmann writes: > > Well, this issue is now fixed in trunk/. I hope you have more success > > with AP5 now. > > Thanks for your report. I'm looking forward to any further reports if > > you have them! > So far I'm having trouble building: > $ svn co svn://common-lisp.net/project/armedbear/svn/trunk/abcl abcl > ... > $ cd abcl/ > $ clisp > [1]> (load "build-abcl.lisp") > ;; Loading file build-abcl.lisp ... > *** - ZEROP: NIL is not a number > > This turns out to be due to the fact that > (ext:run-shell-command "uname | grep -i linux" :output nil) returns NIL. > I change zerop in that line to null as a temporary measure. Is that a released CLISP version? I'm using clisp 2.44 and JDK 1.5/1.6 myself to test our build. Just built with these setups successfully. Unfortunately, I must admit the Ant build is better tested. You're using a newer clisp and a newer JDK? Bye, Erik. |
From: <don...@is...> - 2009-01-19 18:08:53
|
Erik Huelsmann writes: > > ;; Loading file build-abcl.lisp ... > > *** - ZEROP: NIL is not a number > Is that a released CLISP version? I'm using clisp 2.44 and JDK 1.5/1.6 > myself to test our build. Just built with these setups successfully. > Unfortunately, I must admit the Ant build is better tested. This change starts in 2.47. I suggest the test simply be changed to (or (null result)(zerop result)). > You're using a newer clisp and a newer JDK? I'm actually using a newer than released clisp (from cvs) and openjdk from fedora 10. The zerop issue is not the only one. The openjdk javac was also returning non zero: 1. Trace: (RUN-SHELL-COMMAND '"/usr/bin/javac -classpath /tmp/abcl/src:/usr/jre/lib/rt.jar -g -5 -nowarn ReaderMacroFunction.java ... ':DIRECTORY '#P"/tmp/abcl/src/org/armedbear/lisp/") 1. Trace: RUN-SHELL-COMMAND ==> -1 http://clisp.podval.org/impnotes/shell.html says If :STREAM was specified for :INPUT or :OUTPUT, a Lisp STREAM is returned. If :STREAM was specified for both :INPUT and :OUTPUT, three Lisp STREAMs are returned, as for the function EXT:MAKE-PIPE-IO-STREAM. Otherwise, the return value depends on the process termination status: if it exited on a signal or a core-dump, the signal number is returned as a negative INTEGER else, if it ended normally with 0 exit status, NIL is returned; otherwise, the status is returned as a positive INTEGER. So I guess javac exited with signal number 1 - sighup. Whatever that means. As I mentioned, the compile seems to have worked. |
From: Erik H. <eh...@gm...> - 2009-02-15 22:42:37
|
Hi Don, As preparation for a new release, I have changed the code to consider both T and NIL as success returns for EXT:SHELL on clisp. I hope that works for you. For me, it's not needed to try to override any of the build options: if you compile with OpenJDK it should just compile, if it doesn't, we should have a look at it. Can you report errors you get when compiling with OpenJDK? Bye, Erik. On Mon, Jan 19, 2009 at 7:08 PM, Don Cohen <don...@is...> wrote: > Erik Huelsmann writes: > > > ;; Loading file build-abcl.lisp ... > > > *** - ZEROP: NIL is not a number > > > Is that a released CLISP version? I'm using clisp 2.44 and JDK 1.5/1.6 > > myself to test our build. Just built with these setups successfully. > > Unfortunately, I must admit the Ant build is better tested. > This change starts in 2.47. > I suggest the test simply be changed to (or (null result)(zerop result)). > > > You're using a newer clisp and a newer JDK? > I'm actually using a newer than released clisp (from cvs) and openjdk > from fedora 10. > The zerop issue is not the only one. The openjdk javac was also > returning non zero: > 1. Trace: > (RUN-SHELL-COMMAND > '"/usr/bin/javac -classpath /tmp/abcl/src:/usr/jre/lib/rt.jar -g -5 > -nowarn ReaderMacroFunction.java > ... > ':DIRECTORY '#P"/tmp/abcl/src/org/armedbear/lisp/") > 1. Trace: RUN-SHELL-COMMAND ==> -1 > > http://clisp.podval.org/impnotes/shell.html says > If :STREAM was specified for :INPUT or :OUTPUT, a Lisp STREAM is > returned. If :STREAM was specified for both :INPUT and :OUTPUT, three > Lisp STREAMs are returned, as for the function > EXT:MAKE-PIPE-IO-STREAM. Otherwise, the return value depends on the > process termination status: if it exited on a signal or a core-dump, > the signal number is returned as a negative INTEGER else, if it ended > normally with 0 exit status, NIL is returned; otherwise, the status is > returned as a positive INTEGER. > > So I guess javac exited with signal number 1 - sighup. > Whatever that means. > As I mentioned, the compile seems to have worked. > |
From: <don...@is...> - 2009-02-19 03:01:46
|
Erik Huelsmann writes: > As preparation for a new release, I have changed the code to consider > both T and NIL as success returns for EXT:SHELL on clisp. > I hope that works for you. > For me, it's not needed to try to override any of the build options: > if you compile with OpenJDK it should just compile, if it doesn't, we > should have a look at it. Can you report errors you get when compiling > with OpenJDK? I've just tried rebuilding from svn. Other than *jdk*, the only thing I have to change to compile is (setq *javac-options* "-g -5 -nowarn") It seems that the default is 1.4. The end of the build still looks a little suspect: ... ; (DEFUN WRITE-SEQUENCE ...) ; Wrote /tmp/abcl/src/org/armedbear/lisp/write-sequence.abcl (0.026 seconds) 71.246 seconds real time 97090717 cons cells Exception in thread "main" java.io.IOException: can't find class file org/armedbear/lisp/Native.class in java.net.URLClassLoader{urls=[file:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/rt.jar], parent=gnu.gcj.runtime.SystemClassLoader{urls=[file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}} at gnu.classpath.tools.javah.Main.getClass(libgcj-tools.so.9) at gnu.classpath.tools.javah.Main.run(libgcj-tools.so.9) at gnu.classpath.tools.javah.Main.main(libgcj-tools.so.9) /usr/bin/gjavah -o org/armedbear/lisp/native.h org.armedbear.lisp.Native returned 1 Build completed successfully in 86.329216 seconds. T [4]> Bye. Without the nowarn I get 743 warnings. I guess that's ok. 744 warnings with -6. Perhaps you'd like to see them? While I'm at it I try -7 ... looks a lot like -6 |
From: Erik H. <eh...@gm...> - 2009-02-23 23:45:43
|
On Thu, Feb 19, 2009 at 3:02 AM, Don Cohen <don...@is...> wrote: > Erik Huelsmann writes: > > > As preparation for a new release, I have changed the code to consider > > both T and NIL as success returns for EXT:SHELL on clisp. > > I hope that works for you. > > For me, it's not needed to try to override any of the build options: > > if you compile with OpenJDK it should just compile, if it doesn't, we > > should have a look at it. Can you report errors you get when compiling > > with OpenJDK? > I've just tried rebuilding from svn. > Other than *jdk*, the only thing I have to change to compile is > (setq *javac-options* "-g -5 -nowarn") > It seems that the default is 1.4. > > The end of the build still looks a little suspect: > ... > ; (DEFUN WRITE-SEQUENCE ...) > ; Wrote /tmp/abcl/src/org/armedbear/lisp/write-sequence.abcl (0.026 > seconds) > 71.246 seconds real time > 97090717 cons cells > Exception in thread "main" java.io.IOException: can't find class file > org/armedbear/lisp/Native.class in > java.net.URLClassLoader{urls=[file:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/rt.jar], > parent=gnu.gcj.runtime.SystemClassLoader{urls=[file:./], > parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}} > at gnu.classpath.tools.javah.Main.getClass(libgcj-tools.so.9) > at gnu.classpath.tools.javah.Main.run(libgcj-tools.so.9) > at gnu.classpath.tools.javah.Main.main(libgcj-tools.so.9) > /usr/bin/gjavah -o org/armedbear/lisp/native.h > org.armedbear.lisp.Native returned 1 > Build completed successfully in 86.329216 seconds. Ok. If you were to rebuild today, I don't expect errors like the bit above anymore (possibly warnings though): We've shortly discussed the usefulness of that bit of native code and we don't understand it. It's been ripped out now. HTH, Erik. |
From: Erik H. <eh...@gm...> - 2009-02-19 14:54:09
|
On Thu, Feb 19, 2009 at 3:02 AM, Don Cohen <don...@is...> wrote: > Erik Huelsmann writes: > > > As preparation for a new release, I have changed the code to consider > > both T and NIL as success returns for EXT:SHELL on clisp. > > I hope that works for you. > > For me, it's not needed to try to override any of the build options: > > if you compile with OpenJDK it should just compile, if it doesn't, we > > should have a look at it. Can you report errors you get when compiling > > with OpenJDK? > I've just tried rebuilding from svn. > Other than *jdk*, the only thing I have to change to compile is > (setq *javac-options* "-g -5 -nowarn") > It seems that the default is 1.4. > > The end of the build still looks a little suspect: Indeed it does. > ; (DEFUN WRITE-SEQUENCE ...) > ; Wrote /tmp/abcl/src/org/armedbear/lisp/write-sequence.abcl (0.026 > seconds) > 71.246 seconds real time > 97090717 cons cells > Exception in thread "main" java.io.IOException: can't find class file > org/armedbear/lisp/Native.class in > java.net.URLClassLoader{urls=[file:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/rt.jar], > parent=gnu.gcj.runtime.SystemClassLoader{urls=[file:./], > parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}} > at gnu.classpath.tools.javah.Main.getClass(libgcj-tools.so.9) > at gnu.classpath.tools.javah.Main.run(libgcj-tools.so.9) > at gnu.classpath.tools.javah.Main.main(libgcj-tools.so.9) > /usr/bin/gjavah -o org/armedbear/lisp/native.h > org.armedbear.lisp.Native returned 1 > Build completed successfully in 86.329216 seconds. > T > [4]> Bye. >From the above, it looks like you're using the Classpath runtime library and not the Sun version. Although I'm not against supporting Classpath, I haven't tested much with it. Are you using the Sun compiler? Possibly, you could provide us with your configuration settings? I'll need to be at home to see how to check for the different versions of teh Sun and jikes/ gcl compilers. Maybe javac --version or javac --help would already be helpful though. Bye, Erik. |
From: Mark E. <ev...@pa...> - 2009-02-19 15:00:01
|
Erik Huelsmann wrote: […] >>From the above, it looks like you're using the Classpath runtime > library and not the Sun version. Although I'm not against supporting > Classpath, I haven't tested much with it. Are you using the Sun > compiler? Failing to dynamically link to the runtime native shared library is not catastrophic to the further functioning of ABCL. It is currently only used to send unambiguous signals to the JVM for CTRL-C key sequences as far as I can tell. But please share your configuration details. Somehow it has failed to run the Java JNI stub compiler to create the Java description, and we can perhaps patch this for ABCL-0.13. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: <don...@is...> - 2009-02-19 17:33:36
|
Erik Huelsmann writes: > > Exception in thread "main" java.io.IOException: can't find class file > > org/armedbear/lisp/Native.class in > > java.net.URLClassLoader{urls=[file:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/rt.jar], > > parent=gnu.gcj.runtime.SystemClassLoader{urls=[file:./], > > parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}} > > at gnu.classpath.tools.javah.Main.getClass(libgcj-tools.so.9) > > at gnu.classpath.tools.javah.Main.run(libgcj-tools.so.9) > > at gnu.classpath.tools.javah.Main.main(libgcj-tools.so.9) > > /usr/bin/gjavah -o org/armedbear/lisp/native.h > > org.armedbear.lisp.Native returned 1 > > Build completed successfully in 86.329216 seconds. > > T > > [4]> Bye. > > From the above, it looks like you're using the Classpath runtime > library and not the Sun version. Although I'm not against supporting > Classpath, I haven't tested much with it. Are you using the Sun > compiler? I am surprised to discover: $ javac -v Eclipse Java Compiler 0.883_R34x, 3.4.1 release, Copyright IBM Corp 2000, 2008. All rights reserved. I thought I was simply using openjdk. I have installed eclipse, but I didn't expect that to replace javac. $ java -version java version "1.6.0_0" IcedTea6 1.4 (fedora-9.b14.fc10-x86_64) Runtime Environment (build 1.6.0_0-b14) OpenJDK 64-Bit Server VM (build 14.0-b08, mixed mode) Both are in the same place: $ which javac /usr/bin/javac $ which java /usr/bin/java > Possibly, you could provide us with your configuration settings? I'll > need to be at home to see how to check for the different versions of > teh Sun and jikes/ gcl compilers. Maybe javac --version or javac > --help would already be helpful though. Let me know what other info might help. |
From: Alessio S. <ale...@gm...> - 2009-02-19 19:19:08
|
On Thu, Feb 19, 2009 at 6:33 PM, Don Cohen <don...@is...> wrote: > Both are in the same place: > $ which javac > /usr/bin/javac > $ which java > /usr/bin/java be aware that on at least some distributions (e.g. ubuntu) java/javac/javaws/... are actually symlinks to the "default" java implementation installed on the system. Alessio |