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 - gcj-devel exports jni includes in default include path
Summary: gcj-devel exports jni includes in default include path
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-01 12:52 UTC by Daniel Veillard
Modified: 2008-07-10 12:56 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-09 09:15:03 UTC


Attachments (Terms of Use)

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-1.6.0.0.x86_64/include -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-1.6.0.0.x86_64/include -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-1.6.0.0.x86_64/include/jni.h:57: 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):
libgcj-devel-4.3.0-8
java-1.6.0-openjdk-devel-1.6.0.0-0.15.b09.fc9.x86_64

How reproducible:


Steps to Reproduce:
1. select openjdk with alternatives 
2. try to compile libvirt-java code
3. 
  
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
versions

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...

Daniel

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

Daniel



Note You need to log in before you can comment on or make changes to this bug.