Wed 12 Dec 2012 04:57:22 PM UTC, comment #19:
Coooool!
I'll close this report now.
|
Wed 12 Dec 2012 01:05:27 AM UTC, comment #18:
Very good! Build completed OK as far as JAVA goes.
Thanks very much for sticking with this!
|
Tue 11 Dec 2012 10:39:55 PM UTC, comment #17:
You're probably also watching the octave-maintainers list but I pushed some more changes to Java detection in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/fafd51a1b0f0).
'hg pull; hg update; bootstrap; configure' and see whether it gets it right now.
|
Tue 11 Dec 2012 07:45:59 PM UTC, comment #16:
sh-4.2$ java OctJavaQry JAVA_BOOTPATH
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64
|
Tue 11 Dec 2012 07:40:06 PM UTC, comment #15:
Argh! So Java can't correctly find its own library path.
The Atom/amd64 thing isn't an issue. The architecture for all x86 compatible processors using 64-bit instructions is amd64.
I'm uploading another Java attempt to this bug report. The file is <OctJavaQry.class>.
Could you download it somewhere, cd to that directory, and then run
What path did that return?
(file #27072)
|
Tue 11 Dec 2012 07:11:01 PM UTC, comment #14:
sh-4.2$ locate libjvm.so
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/server/libjvm.so
s
This is strange since /proc/cpuinfo says:
Intel(R) Atom(TM) CPU D525 @ 1.80GHz
|
Tue 11 Dec 2012 07:06:04 PM UTC, comment #13:
Right. Should have noticed that. Now:
sh-4.2$ JAVA_TMP_LDPATH=`echo $JAVA_TMP_LDPATH | sed -e 's/^://' -e 's/:$//' -e 's/://g'`
sh-4.2$ echo $JAVA_TMP_LDPATH
sh-4.2$
|
Tue 11 Dec 2012 06:58:45 PM UTC, comment #12:
Michael, I think the last error is a cut-n-paste error with the code boxes on Savannah and not more serious.
So, the question is whether Java can report its own library path correctly. At least it did return something. Do you have a libjvm.so in any of the reported paths [/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]?
I would suggest 'locate libjvm.so' and see what that says.
|
Tue 11 Dec 2012 06:55:36 PM UTC, comment #11:
The build failure when compiling without Java is a result of JWE moving things from the dynamically linked directory (dldfcn) into the core. I'm going to have to let him tackle that after getting the rest of the process going.
|
Tue 11 Dec 2012 06:40:56 PM UTC, comment #10:
I tried, but:
[pbdsl3:build-aux] /bin/sh
sh-4.2$ JAVA="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/bin/java"
sh-4.2$ export JAVA
sh-4.2$
sh-4.2$ JAVA_TMP_LDPATH=`$JAVA OctJavaQry JAVA_LDPATH`
sh-4.2$ echo $JAVA_TMP_LDPATH
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
sh-4.2$
sh-4.2$ JAVA_TMP_LDPATH=`echo $JAVA_TMP_LDPATH | sed -e 's/^://' -e 's/:$//' -e 's/:/
> /g'`
sed: -e expression #3, char 4: unterminated `s' command
sh-4.2$ echo $JAVA_TMP_LDPATH
sh-4.2$
|
Tue 11 Dec 2012 06:06:48 PM UTC, comment #9:
Also worth noting that dev won't build currently if Java is disabled. The build fails in ov.cc because it unconditionally pulls in ov-java.h and uses the octave_java class, which depends on a bunch of JNI types. The first error from make is indeed about the missing jni.h include file.
|
Tue 11 Dec 2012 05:31:20 PM UTC, comment #8:
libjvm.so is not being found and this is because the JAVA_LDPATH variable is probably not getting set correctly.
Could you use a Bourne shell, as configure does, and try the following? You will need to cd to the Octave top-level source directory and then into the directory build-aux in order to find OctJavaQry.class.
|
Tue 11 Dec 2012 04:10:10 PM UTC, comment #7:
Rik,
I tried 2 more things:
1. setenv setenv JAVA_HOME /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64
2. ln -s /lib/jvm/java-openjdk/include/ /usr/lib/jvm/include
Neither worked.
So, right now I cannot configure java. Sorry.
|
Tue 11 Dec 2012 03:29:00 AM UTC, comment #6:
Can you attach config.log too? config.status is reporting that JAVA_LDPATH is unset, but now I need to see how that happened.
|
Tue 11 Dec 2012 03:06:00 AM UTC, comment #5:
Rik,
Sorry. I misread config output:
Build Octave GUI: true
JIT compiler for loops: true
Build Java interface: false
jit is OK, but not java
./configure --enable-jit | tee config.log
config.status attached
(file #27067)
|
Tue 11 Dec 2012 12:41:59 AM UTC, comment #4:
OK looks better. But now
./configure --enable-jit
seems to be broken
|
Tue 11 Dec 2012 12:25:05 AM UTC, comment #3:
Changes to configure.ac aren't propagated to configure unless you run the bootstrap script.
Try 'hg pull; hg update; bootstrap; configure; make'
I think you can also do 'hg pull; hg update; make' and the Makefiles will detect that configure.ac has changed and will re-run Automake, configure cycle.
|
Tue 11 Dec 2012 12:17:06 AM UTC, comment #2:
I tried this by hg pull;hg update;./configure
but got:
octave-value/ov-java.h:26:17: fatal error: jni.h: No such file or directory
The configureation that it chose was like one before that did
not work.
Should I try a new hg clone?
In the end, on my fc17 the include:
/lib/jvm/java-openjdk/include/
or something with jni.h needs to be found.
|
Mon 10 Dec 2012 11:24:00 PM UTC, comment #1:
As of changeset 15763:56239ff815a3, configure now explicitly tries to find jni.h and will not build the Java interface if it cannot be found.
|
Fri 07 Dec 2012 01:37:16 PM UTC, original submission:
The current dev system fails due to cannot find jni.h
on my fc17 X86_64 system. This is due to the use of:
/usr/lib/jvm/include
as the source for jni.h. However, there is no "include"
in /usr/lib/jvm/
So, the following link fixes the problem, but is not
the right permanent solution:
ln -s /lib/jvm/java-openjdk/include/ /usr/lib/jvm/include
The Java configuration stuff is sure in a mess. And, I have
no idea what is a good way to fix this build problem.
|