I have the Sun JDK installed on FC2 using the -compat package from JPackage and I'm trying to rebuild the new subversion-1.3.0-2 SRPM. I get a bunch of compile errors for the javahl subpackage from what appear to be header incompatibilities. Has anyone tried this?
(I had to patch the subversion spec file to use the more generic link to the JDK and to set the BuildRequires to the generic JDK-compat Provides instead of the gcj-specific one.)
I'll reply back to this thread as I learn more, with more details about exactly what is happening. I just wanted to see if anyone else has tried substituting the Sun JDK for gcj and run into something similar.
"Kenneth" == Kenneth Porter shiva@sewingwitch.com writes:
Kenneth> I have the Sun JDK installed on FC2 using the -compat package from Kenneth> JPackage and I'm trying to rebuild the new subversion-1.3.0-2 SRPM. I Kenneth> get a bunch of compile errors for the javahl subpackage from what Kenneth> appear to be header incompatibilities. Has anyone tried this?
I haven't tried this. What kind of header incompatibilities do you get? Could you post some of the error messages?
Kenneth> I'll reply back to this thread as I learn more, with more details Kenneth> about exactly what is happening. I just wanted to see if anyone else Kenneth> has tried substituting the Sun JDK for gcj and run into something Kenneth> similar.
In theory the headers we export (mostly jni.h) should be both source- and binary-compatible with Sun.
The same should hold true for JNI headers generated by javah, but I think we have a couple known 'gcjh -jni' buglets. In your case, though, I'd expect you're using the "real" javah, and thus "shouldn't" see this.
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tom Tromey wrote:
I haven't tried this. What kind of header incompatibilities do you get? Could you post some of the error messages?
Another packager reported to me this same issue. Using kaffe's jni headers (i.e., using kaffe instead of gcj) worked for him. This was against gcj 4.0.x, but maybe the problem still exists.
In theory the headers we export (mostly jni.h) should be both source- and binary-compatible with Sun.
Ideally.
- -- Sincerely,
David Walluck david@zarb.org
Looks like the root of my issue is here:
/usr/lib/jvm/java/include/jni.h:27:20: jni_md.h: No such file or directory
The referenced file is located here:
/usr/lib/jvm/java/include/linux/jni_md.h
And:
[buildmeister@segw include]$ rpm -qf /usr/lib/jvm/java/include/jni.h j2sdk-1.4.2_10-fcs
So this looks like Sun's bug.
On Sunday, January 08, 2006 11:31 PM -0800 Kenneth Porter shiva@sewingwitch.com wrote:
Looks like the root of my issue is here:
/usr/lib/jvm/java/include/jni.h:27:20: jni_md.h: No such file or directory
The referenced file is located here:
/usr/lib/jvm/java/include/linux/jni_md.h
And:
[buildmeister@segw include]$ rpm -qf /usr/lib/jvm/java/include/jni.h j2sdk-1.4.2_10-fcs
So this looks like Sun's bug.
I added a symlink in /usr/java/j2sdk1.4.2_10/include:
jni_md.h -> linux/jni_md.h
This allows Subversion's javahl subpackage to build.
Is this a bug in the header, or should the linux subdirectory be in the header search path?
java-devel@lists.fedoraproject.org