Bug 453572 - gcj-devel exports jni includes in default include path
gcj-devel exports jni includes in default include path
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-01 08:52 EDT by Daniel Veillard
Modified: 2008-07-10 08:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-09 05:15:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Veillard 2008-07-01 08:52:46 EDT
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 03:07:06 EDT
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 10:12:33 EDT
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 08:56:25 EDT
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.