This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented



------- Comment #23 from rob1weld at aol dot com  2007-01-18 23:52 -------
I compiled 4.1.1 on Windows XP (Cygwin) a couple of days ago and did not have
the "Found a problem with the JNI methods declared and implemented." message
occur.

Last week when I compiled gcc-4_2-branch (SVN) the error did not occur.
Today, when I recompiled 4.2.0 it DID occur.

I am using the same parameters to configure (and compiling in a different
directory than the source) as I did previously so either the SVN source
breakage is recent (for i686-pc-cygwin platform) or my system had something
occur recently to change things. I am using the same (lengthy) parameters
for both 4.1.1 and 4.2.0 (though 4.2.0 has more implemented when these same
parameters are used).

I am concerned that the list is rather long, here is part of it:

make[6]: Entering directory
`/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava/classpath/native/jni'
cd /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/classpath && /bin/sh
./scripts/check_jni_methods.sh
Found a problem with the JNI methods declared and implemented.
(-) missing in implementation, (+) missing in header files
+Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoArc
+Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoClip
+Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoClosePath
+Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoCurveTo
+Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoDrawGlyphVector
+Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoDrawLine
...
+Java_gnu_xml_libxmlj_sax_GnomeLocator_systemId
+Java_gnu_xml_libxmlj_sax_GnomeXMLReader_parseStream
+Java_gnu_xml_libxmlj_transform_GnomeTransformerFactory_freeLibxsltGlobal
+Java_gnu_xml_libxmlj_transform_GnomeTransformer_free
+Java_gnu_xml_libxmlj_transform_GnomeTransformer_newStylesheet
+Java_gnu_xml_libxmlj_transform_GnomeTransformer_newStylesheetFromDoc
+Java_gnu_xml_libxmlj_transform_GnomeTransformer_newStylesheetFromStream
+Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformDocToDoc
+Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformDocToSAX
+Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformDocToStream
+Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformStreamToDoc
+Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformStreamToSAX
+Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformStreamToStream
make[6]: *** [all-local] Error 1


Looking through the long list I noticed this group and set out to find it:

+Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1add_1dir
+Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1dir_1exists
+Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1gconf_1client_1all_1keys
+Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1gconf_1client_1all_1nodes
+Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1get_1string
+Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1remove_1dir
+Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1set_1string
+Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1suggest_1sync
+Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1unset


I found it in my SOURCE directory (not my build directry). It is odd that make
runs commands that toss files into your source directory - seems to run against
general principles of having the directories seperate.

I looked at this file that gcjh had created -
/cygdrive/C/makecygwin/gcc-4_2-branch/libjava/classpath/include/gnu_java_util_prefs_gconf_GConfNativePeer.h
and found this in it:

extern JNIEXPORT void JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_init_1id_1cache (JNIEnv *env,
jclass);
extern JNIEXPORT void JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_init_1class (JNIEnv *env,
jclass);
extern JNIEXPORT void JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_finalize_1class (JNIEnv *env,
jclass);
extern JNIEXPORT jboolean JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1dir_1exists
(JNIEnv *env, jclass, jstring);
extern JNIEXPORT void JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1add_1dir (JNIEnv
*env, jclass, jstring);
extern JNIEXPORT void JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1remove_1dir
(JNIEnv *env, jclass, jstring);
extern JNIEXPORT jboolean JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1set_1string
(JNIEnv *env, jclass, jstring, jstring);
extern JNIEXPORT jstring JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1get_1string
(JNIEnv *env, jclass, jstring);
extern JNIEXPORT jboolean JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1unset (JNIEnv
*env, jclass, jstring);
extern JNIEXPORT void JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1suggest_1sync
(JNIEnv *env, jclass);
extern JNIEXPORT jobject JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1gconf_1client_1all_1nodes
(JNIEnv *env, jclass, jstring);
extern JNIEXPORT jobject JNICALL
Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1gconf_1client_1all_1keys
(JNIEnv *env, jclass, jstring);


Thats what the check script thought was missing (amoungst many others). I made
a copy of the check script any modified it like this:

# Origonal
## Find all methods defined in the header files generated
## from the java source files.
#grep -h '^JNIEXPORT .* Java_' include/*.h | \
#        LC_ALL=C sed -e 's,.*JNICALL \(Java_[a-z_A-Z0-9]*\).*$,\1,' | \
#       sort > $TMPFILE

# New
# Find all methods defined in the header files generated
# from the java source files.
grep -h 'JNIEXPORT .* Java_' include/*.h | \
        LC_ALL=C sed -e 's,.*JNICALL \(Java_[a-z_A-Z0-9]*\).*$,\1,' | \
        sort > $TMPFILE

That will disregard the "extern" prefix to "JNIEXPORT". I re-ran my modified
copy of the check_jni_methods.sh script and got a MUCH shorter list of problems
plus now there where a few "-" errors (missing in implementation) too.

Here is a small portion of the output:

Found a problem with the JNI methods declared and implemented.
(-) missing in implementation, (+) missing in header files
-Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getGlyphs___3I
+Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getGlyphs
-Java_gnu_java_awt_peer_gtk_GdkFontPeer_getFontMetrics___3D
+Java_gnu_java_awt_peer_gtk_GdkFontPeer_getFontMetrics
-Java_gnu_java_awt_peer_gtk_GtkButtonPeer_create__Ljava_lang_String_2
+Java_gnu_java_awt_peer_gtk_GtkButtonPeer_create
-Java_gnu_java_awt_peer_gtk_GtkEmbeddedWindowPeer_create__J
+Java_gnu_java_awt_peer_gtk_GtkEmbeddedWindowPeer_create
-Java_gnu_java_awt_peer_gtk_GtkFileDialogPeer_create__Lgnu_java_awt_peer_gtk_GtkContainerPeer_2I
+Java_gnu_java_awt_peer_gtk_GtkFileDialogPeer_create
-Java_gnu_java_awt_peer_gtk_GtkFramePeer_getMenuBarHeight__Ljava_awt_peer_MenuBarPeer_2
+Java_gnu_java_awt_peer_gtk_GtkFramePeer_getMenuBarHeight
-Java_gnu_java_awt_peer_gtk_GtkGenericPeer_gtkWidgetModifyFont__Ljava_lang_String_2II
+Java_gnu_java_awt_peer_gtk_GtkGenericPeer_gtkWidgetModifyFont
-Java_gnu_java_awt_peer_gtk_GtkLabelPeer_create__Ljava_lang_String_2F
+Java_gnu_java_awt_peer_gtk_GtkLabelPeer_create
-Java_gnu_java_awt_peer_gtk_GtkListPeer_create__I
+Java_gnu_java_awt_peer_gtk_GtkListPeer_create


Disregarding the "-" output and only considering the "+" lines I wonder how it
would compile with those ".h" files missing; though I now have a MUCH shorter
list than before. I'm not a Java expert, but something is fishy.


If the "gcjh part of the Makefile, like this:

/usr/bin/gcjh -jni -bootclasspath ../lib: -o
/cygdrive/C/makecygwin/gcc-4_2-branch/libjava/classpath/include/gnu_java_ut
il_prefs_gconf_GConfNativePeer.h gnu.java.util.prefs.gconf.GConfNativePeer

1) Output to the BUILD directory.
2) Found all the needed .class files.
3) Made a list of what it couldn't find.

Then when we got to the check_jni_methods.sh part of the Makefile it could read
in a "TMPFILE3" (temporary ignore file) that was correct (and in the case of
4.2.0 SVN, updated as needed) and we could all put this bug to rest.

Currently I'm using "make -i all-target-libjava" to push my way through.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]