Hi,
With this patch, if the $java_gnome local is evaluated to /usr, then
the $jni_include variable will not be set to -I/usr/include
-I/usr/include/linux.
This fixes rampant build errors in the JNI code, encountered on e.g.
Ubuntu when this is the case.
Since the existing code already omits the $jni_include variable when
jni.h is in /usr/include, I surmise that this additional check will
not break any existing setups where it currently works.
Testing is desired, as are attempts to break it.
What would happen if $java_gnome is "/usr/lib/jdk_1.6.0_03/../../"?
Well, it'd evaluate to /usr/ again, and the compiler would eventually
be fed -I/usr/lib/jdk_1.6.0_03/../../include/linux, which evaluates to
-I/usr/include/linux, which breaks the build. So no, this method is
not bullet-proof.
It would be even more robust if we could evaluate $jni_include as a
path and see if that path equals /usr. But I am not proficient in perl
so I do not know how to pull this off. Sorry...
Anyway, this fixes my build error and seems relatively safe, since the
script pretty much assumes that when you compile something that does
#include <stdio.h> without any -I flags, it'll resolve it to
"/usr/include/stdio.h".
If we want to abstract away from reliance on /usr/include, I'd be
happy to look into this further -- but the end result is that I want
to guarantee that -I/usr/include and -I/usr/include/linux do NOT
appear in my cflags, since this breaks the build.
Maybe there's an even easier post-processing way to do this?
If we were using the Perl equivalent of a Java StringWriter, we could
grab the final output to the file just before writing .config.tmp and
nuke all occurrences of -I/usr/include -I/usr/include/linux.
Finally, for the record:
sean@vk5rms:~/java-gnome/missing$ echo $JAVA_HOME
sean@vk5rms:~/java-gnome/missing$
I haven't investigated why this script determines that my $java_home is "/usr".
Thanks,
Sean McNamara
|
