[BRLTTY] jni.h?

[Dave Mielke]

[quoted lines by Mario Lang on 2007/09/04 at 00:48 +0200]

>On i386 I have:
>fzidpc73:/# uname -a
>Linux fzidpc73 2.6.18-3-686 #1 SMP Sun Dec 10 19:37:06 UTC 2006 i686 GNU/Linux
>fzidpc73:/# find /usr/lib -name jni.h
>/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/jni.h
>/usr/lib/gcc/i486-linux-gnu/4.2/include/jni.h
>
>and on amd64 I have:
>x2:/# uname -a
>Linux x2 2.6.22-1-amd64 #1 SMP Sun Jul 29 13:54:41 UTC 2007 x86_64 GNU/Linux
>x2:/# find /usr/lib -name jni.h
>/usr/lib/gcc/x86_64-linux-gnu/4.1/include/jni.h
>/usr/lib/gcc/x86_64-linux-gnu/4.2/include/jni.h
>/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/include/jni.h
>
>Does anyone have the slightest idea why our configure script
>does not find jni.h on an i386 host?

It's not an i386 vs x86_64 problem. The configure script doesn't care about 
that. It has to be something about the system layout.

The first thing the configure script does is check if $JAVA_HOME is defined. Is 
it defined on one system but not on the other? If so, that may be the source of 
the problem. Also, if you want to force which Java will be used then setting 
$JAVA_HOME before configuring is the way to do it.

If $JAVA_HOME isn't set then the configure script looks for javac in a few 
well-known places (/usr/java, /usr/java/jdk*), and then for either javac or gcj 
in the current command search path. If the compiler can be found then it checks 
for /path/to/javac-or-gcj/../include/jni.h. If that can't be found then it 
checks to see if gcc can find it anyway.

Now for my guess. I think gcc is finding it on its own on the one platform but 
not on the other.

-- 
Dave Mielke           | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario   | Word of God. Please contact me
EMail: dave at mielke.cc | Canada  K2A 1H7   | if you're concerned about Hell.
http://FamilyRadio.com/                   | http://Mielke.cc/bible/