Bug 453572
| Summary: | gcj-devel exports jni includes in default include path | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Daniel Veillard <veillard> |
| Component: | gcc | Assignee: | 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 | ||
| Whiteboard: | |||
| 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: | |
| Embargoed: | |||
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. 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 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 |
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