public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rob1weld at aol dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libgcj/27823] Found a problem with the JNI methods declared and implemented Date: Thu, 18 Jan 2007 23:52:00 -0000 [thread overview] Message-ID: <20070118235240.15334.qmail@sourceware.org> (raw) In-Reply-To: <bug-27823-12755@http.gcc.gnu.org/bugzilla/> ------- 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
next prev parent reply other threads:[~2007-01-18 23:52 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-05-30 13:01 [Bug java/27823] New: " william-paul dot philibert at telus dot com 2006-06-05 14:14 ` [Bug libgcj/27823] " tromey at gcc dot gnu dot org 2006-06-14 14:20 ` WILLIAMPAUL dot PHILIBERT at telus dot com 2006-06-14 17:50 ` tromey at gcc dot gnu dot org 2006-07-08 15:28 ` lucier at math dot purdue dot edu 2006-07-08 15:50 ` pinskia at gcc dot gnu dot org 2006-07-08 18:13 ` lucier at math dot purdue dot edu 2006-07-08 21:45 ` ebotcazou at gcc dot gnu dot org 2006-07-08 22:05 ` lucier at math dot purdue dot edu 2006-07-20 0:25 ` bass at 2ka dot mipt dot ru 2006-09-21 2:24 ` jblaine at mitre dot org 2006-09-21 12:18 ` WILLIAMPAUL dot PHILIBERT at telus dot com 2006-09-21 14:09 ` jblaine at mitre dot org 2006-09-21 14:20 ` WILLIAMPAUL dot PHILIBERT at telus dot com 2006-09-21 14:22 ` jblaine at mitre dot org 2006-09-21 14:32 ` ebotcazou at gcc dot gnu dot org 2006-09-21 14:38 ` lucier at math dot purdue dot edu 2006-09-21 14:49 ` WILLIAMPAUL dot PHILIBERT at telus dot com 2006-09-21 16:04 ` jblaine at mitre dot org 2006-09-21 16:09 ` ebotcazou at gcc dot gnu dot org 2006-09-21 16:22 ` lucier at math dot purdue dot edu 2006-09-21 17:02 ` tromey at gcc dot gnu dot org 2006-09-21 17:57 ` ebotcazou at gcc dot gnu dot org 2007-01-18 23:52 ` rob1weld at aol dot com [this message] 2008-07-24 1:59 ` Riot dot Nrrrd dot Bugzilla at isolar dot DynDNS dot ORG
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20070118235240.15334.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).