Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 453572

Summary: gcj-devel exports jni includes in default include path
Product: [Fedora] Fedora Reporter: Daniel Veillard <veillard>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-09 09:15:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Daniel Veillard 2008-07-01 12:52:46 UTC
Description of problem:
when compiling libvirt-java JNI code while using java-1.6.0-openjdk-devel
for the stub generation and headers, the resulting C stub code compiled with
gcc uses jni.h and jni_md.h from gcj-devel if that one is installed.
Problem is that they conflict too:

make[4]: Entering directory `/u/veillard/libvirt-java/src/jni'
/bin/sh ../../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../..
   -I/usr/lib/jvm/java-1.6.0-openjdk- -g -O2 -MT
libvirt_jni_la-org_libvirt_VirNetwork.lo -MD -MP -MF
.deps/libvirt_jni_la-org_libvirt_VirNetwork.Tpo -c -o
libvirt_jni_la-org_libvirt_VirNetwork.lo `test -f 'org_libvirt_VirNetwork.c' ||
echo './'`org_libvirt_VirNetwork.c
mkdir .libs
 gcc -DHAVE_CONFIG_H -I. -I../..
-I/usr/lib/jvm/java-1.6.0-openjdk- -g -O2 -MT
libvirt_jni_la-org_libvirt_VirNetwork.lo -MD -MP -MF
.deps/libvirt_jni_la-org_libvirt_VirNetwork.Tpo -c org_libvirt_VirNetwork.c 
-fPIC -DPIC -o .libs/libvirt_jni_la-org_libvirt_VirNetwork.o
In file included from org_libvirt_VirNetwork.h:3,
                 from org_libvirt_VirNetwork.c:2:
/usr/lib/jvm/java-1.6.0-openjdk- error:
conflicting types for 'jboolean'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/include/jni_md.h:81: error: previous
declaration of 'jboolean' was here
make[4]: *** [libvirt_jni_la-org_libvirt_VirNetwork.lo] Error 1

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. select openjdk with alternatives 
2. try to compile libvirt-java code
Actual results:

conflict of header 

Expected results:

no conflict

Additional info:

the includes should probably not be exported to the compiler by default,
or if it is the case they should be made compatible between the two

Comment 1 Jakub Jelinek 2008-07-02 07:07:06 UTC
IMNSHO it is perfectly fine as is, I don't see a reason why it should be hidden
in any way.
When you compile against openjdk, just make sure its include directories are all
mentioned in -I options.  The above sounds like you are including some gcj-devel
header (as jni_md.h is gcc specific, while jni.h is not).
Preprocessed source (perhaps with -E -dD even better) might reveal where exactly
is the problem.

Comment 2 Daniel Veillard 2008-07-07 14:12:33 UTC
Yes the system specific $JAVA_HOME/include/linux include path was missing
on the command line. 
Still i still consider a bug that normal gcc exports GCJ JNI header paths
especially when the OpenJDK and GCJ includes are not compatible. that's
call header pollution IMHO, you're spreading into a namespace where you
don't have control. Using gcc as the compiler should not mean you might be
using the gcj JNI include files. that looks just like a recipe for 
broken compile, broken projects (because their JNI code compile even though
they forgot to add the include paths).
I'm ready to bet that fixing that bug will expose various problems in the
way JNI bindings are compiled left and right...


Comment 3 Daniel Veillard 2008-07-10 12:56:25 UTC
Not So humble Opinion indeed... switching to CLOSED NOTABUG while not even
looking at the incompatibility of the headers means you really don't want
to be bothered ... I did post that bug after having asked feedback from
people on the java and tools internal channels, and people stated the
gcj headers really should be fixed because a guard for header inclusion was
missing. You don't care, okay