[Bug java/27823] New: Found a problem with the JNI methods declared and implemented

[Bug java/27823] New: Found a problem with the JNI methods declared and implemented

[william-paul dot philibert at telus dot com]

When I do make a gmake bootstrap of GCC 4.1.1 I have the following output:

gmake[9]: Entering directory
`/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava/classpath/native/jni'
cd /opt/local/src/gcc-4.1.1/libjava/classpath && /bin/ksh
./scripts/check_jni_methods.sh
Found a problem with the JNI methods declared and implemented.
(-) missing in implementation, (+) missing in header files
-Java_gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice_close_1
-Java_gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice_open_1
gmake[9]: *** [all-local] Error 1
gmake[9]: Leaving directory
`/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava/classpath/native/jni'
gmake[8]: *** [all-recursive] Error 1
gmake[8]: Leaving directory
`/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava/classpath/native/jni'
gmake[7]: *** [all-recursive] Error 1
gmake[7]: Leaving directory
`/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava/classpath/native'
gmake[6]: *** [all-recursive] Error 1
gmake[6]: Leaving directory
`/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava/classpath'
gmake[5]: *** [all-recursive] Error 1
gmake[5]: Leaving directory
`/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava'
gmake[4]: *** [multi-do] Error 1
gmake[4]: Leaving directory
`/opt/local/src/gcc-obj/sparc-sun-solaris2.9/libjava'
gmake[3]: *** [all-multi] Error 2
gmake[3]: Leaving directory
`/opt/local/src/gcc-obj/sparc-sun-solaris2.9/libjava'
gmake[2]: *** [all-target-libjava] Error 2
gmake[2]: Leaving directory `/opt/local/src/gcc-obj'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/opt/local/src/gcc-obj'
gmake: *** [bootstrap] Error 2

I have the same problem whether I am use /usr/bin/ccs/ld&as of gnu component.

The CONFIG_SHELL is /bin/ksh

Compiling on a SunFire V240 with Solaris 9

I am in gcc-obj directory wich is no the source dir.

Thanks

William


-- 
           Summary: Found a problem with the JNI methods declared and
                    implemented
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: william-paul dot philibert at telus dot com


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

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

[tromey at gcc dot gnu dot org]

------- Comment #1 from tromey at gcc dot gnu dot org  2006-06-05 14:12 -------
Thanks for reporting this.

Offhand I suspect the problem is that we aren't building this
native code, and thus the checking script gets confused.
Probably we should disable these checks.
I will find out.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-06-05 14:12:44
               date|                            |


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

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

[WILLIAMPAUL dot PHILIBERT at telus dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]



------- Comment #2 from WILLIAMPAUL dot PHILIBERT at telus dot com  2006-06-14 14:12 -------
Subject: RE:  Found a problem with the JNI methods declared and implemented

Do you have any development concerning this bug?

I did modify the code so it does not do the checking and it works fine but do I
miss something by doing this?

William Paul Philibert
Administrateur UNIX et SAN
william-paul.philibert@telus.com
Hébergement
Telus Corporation Inc.


-- 


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

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

[tromey at gcc dot gnu dot org]

------- Comment #3 from tromey at gcc dot gnu dot org  2006-06-14 17:48 -------
I haven't looked at this since my last comment.

Your workaround is fine, you didn't break anything.

A real fix would have to work differently though.
Perhaps we should always compile these functions but just
have them throw exceptions if the libraries are not available.
Or perhaps the checking script should be smarter. I'm not sure.


-- 


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

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

[lucier at math dot purdue dot edu]

------- Comment #4 from lucier at math dot purdue dot edu  2006-07-08 15:28 -------
Has any progress been made on this bug?  I'm kind of surprised that a bootstrap
failure on sparc-solaris should be marked P3.

Brad


-- 

lucier at math dot purdue dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lucier at math dot purdue
                   |                            |dot edu


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-07-08 15:49 -------
This works for other people so I don't know what is going on.


-- 


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

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

[lucier at math dot purdue dot edu]

------- Comment #6 from lucier at math dot purdue dot edu  2006-07-08 18:13 -------
Subject: Re:  Found a problem with the JNI methods declared and implemented

Well, these were the commands that failed:

build.log:cd ../../../../../../../libjava/classpath && /usr/bin/ksh ./ 
scripts/check_jni_methods.sh
build.log:cd ../../../../../../libjava/classpath && /usr/bin/ksh ./ 
scripts/check_jni_methods.sh

and this is what I ended up commenting out in the Makefiles:

sparc-sun-solaris2.9/libjava/classpath/native/jni/Makefile:#    cd $ 
(top_srcdir) && $(SHELL) ./scripts/check_jni_methods.sh
sparc-sun-solaris2.9/sparcv9/libjava/classpath/native/jni/ 
Makefile:#    cd $(top_srcdir) && $(SHELL) ./scripts/ 
check_jni_methods.sh

Maybe it works for people using bash as their CONFIG_SHELL.

Brad


-- 


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

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

[ebotcazou at gcc dot gnu dot org]

------- Comment #7 from ebotcazou at gcc dot gnu dot org  2006-07-08 21:45 -------
Strange, this works for me with CONFIG_SHELL=/bin/ksh on Solaris 8, 9 and 10:
  http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg00356.html
  http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg00357.html
  http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg00358.html

It's with Sun as and ld.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


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

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

[lucier at math dot purdue dot edu]

------- Comment #8 from lucier at math dot purdue dot edu  2006-07-08 22:04 -------
Subject: Re:  Found a problem with the JNI methods declared and implemented

Things really seem screwed up in my build log.

Here's what I see:

make[7]: Entering directory `/export/users/lucier/programs/gcc/ 
gcc-4.1.1/objdir/sparc-sun-solaris2.9/libjava/classpath/native/jni'
cd ../../../../../../libjava/classpath && /usr/bin/ksh ./scripts/ 
check_jni_methods.sh

If you count the number of ../'s in the cd, you see you're back in  
'the source directory'/libjava/classpath when you execute the script,  
so you get

zuse-182% /bin/ksh ./libjava/classpath/scripts/check_jni_methods.sh
find: native/jni: No such file or directory
find: native/jni: No such file or directory
find: native/jni: No such file or directory

If you execute it by hand in the directory where it should be run, it  
seems to work just fine (this is after the completed bootstrap, though):

zuse-185% pu sparc-sun-solaris2.9/libjava/classpath/
~/programs/gcc/gcc-4.1.1/objdir/sparc-sun-solaris2.9/libjava/ 
classpath ~/programs/gcc/gcc-4.1.1/objdir ~/programs/gcc/gcc-4.1.1/ 
objdir/sparc-sun-solaris2.9/sparcv9/libjava/classpath/native/jni ~
zuse-186% /bin/ksh ../../../../libjava/classpath/scripts/ 
check_jni_methods.sh


-- 


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

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

[bass at 2ka dot mipt dot ru]

------- Comment #9 from bass at 2ka dot mipt dot ru  2006-07-20 00:25 -------
I was having a problem related to this one while building gcc on
pentium3-pc-linux-gnu, but I'm not sure whether I should file a separate bug.

Host compiler was gcc-3.4.6, and I passed the ``--enable-regen-headers'' option
to the topmost configure script. Unfortunately, host gcjh (v3.4.6) instead of
bootstrapped one was invoked to regenerate JNI headers, and, buggy as it was,
produced incorrect output, which prevented further builds with ``--enable-jni''
option.

I consider it a bug, and one of the three posible resolutions should be
considered:

1) ``--enable-regen-headers'' option passed to the topmost configure script
should be blocked/disabled/whatever; or

2) ``--enable-regen-headers'' option should not be accepted unless host gcjh is
``modern'' enough (say, 4.0.0); or

3) if configure script is passed the ``--enable-regen-headers'' option, headers
should be regenerated using bootstrapped gcjh, not host one.


-- 

bass at 2ka dot mipt dot ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bass at 2ka dot mipt dot ru


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

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

[jblaine at mitre dot org]

------- Comment #10 from jblaine at mitre dot org  2006-09-21 02:24 -------
Subject: Re:  New: Found a problem with the JNI methods declared
 and implemented

Found this thread in the bug mailing list archives.

I have the same problem :(

Is there a fix more specific than "disable that test" so
I can proceed?  Details?  Does that mean just comment out
the call to check_jni_methods.sh in .......Makefile?


-- 


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

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

[WILLIAMPAUL dot PHILIBERT at telus dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]



------- Comment #11 from WILLIAMPAUL dot PHILIBERT at telus dot com  2006-09-21 12:18 -------
Subject: RE:  Found a problem with the JNI methods declared and implemented

It is the only solution I found.  The problem does not exist with Solaris 10 ! 



William Paul Philibert
Administrateur UNIX et SAN
william-paul.philibert@telus.com
Hébergement
Telus Corporation Inc.
(418) 722-1280

-----Message d'origine-----
De : jblaine at mitre dot org [mailto:gcc-bugzilla@gcc.gnu.org] 
Envoyé : 20 septembre 2006 22:25
À : William-Paul Philibert
Objet : [Bug libgcj/27823] Found a problem with the JNI methods declared and
implemented



------- Comment #10 from jblaine at mitre dot org  2006-09-21 02:24 -------
Subject: Re:  New: Found a problem with the JNI methods declared
 and implemented

Found this thread in the bug mailing list archives.

I have the same problem :(

Is there a fix more specific than "disable that test" so
I can proceed?  Details?  Does that mean just comment out
the call to check_jni_methods.sh in .......Makefile?


-- 


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

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

[jblaine at mitre dot org]

------- Comment #12 from jblaine at mitre dot org  2006-09-21 14:09 -------
FWIW, this fails for me in the exact same way under Red Hat
Enterprise Linux v3.

Both of my 4.1.1 builds are complete failures at this point
(the other being Solaris 9 mentioned above, and yeah I used
CONFIG_SHELL=/bin/ksh there)


-- 

jblaine at mitre dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jblaine at mitre dot org


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

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

[WILLIAMPAUL dot PHILIBERT at telus dot com]

------- Comment #13 from WILLIAMPAUL dot PHILIBERT at telus dot com  2006-09-21 14:20 -------
Subject: RE:  Found a problem with the JNI methods declared and implemented


Just in case, are you building outside the source directory!?

setenv CONFIG_SHELL /bin/ksh
mkdir /usr/local/build-gcc-4.1.1
cd /usr/local/build-gcc-4.1.1
/usr/local/gcc-4.1.1/configure --with-ld=/usr/ccs/bin/ld
                                       --with-as=/usr/ccs/bin/as
                                       --prefix=/usr/local
                                       --with-libiconv-prefix=/usr/local

Those are working fine in Solaris 10

William Paul Philibert


-- 


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

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

[jblaine at mitre dot org]

------- Comment #14 from jblaine at mitre dot org  2006-09-21 14:22 -------
I'm building in a 'foo' directory I made at the top of the unpackaged source
tree.

mkdir foo
cd foo
../configure


-- 


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

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

[ebotcazou at gcc dot gnu dot org]

------- Comment #15 from ebotcazou at gcc dot gnu dot org  2006-09-21 14:31 -------
> mkdir foo
> cd foo
> ../configure

Beginner error I'm afraid. :-)  See http://gcc.gnu.org/install/configure.html


-- 


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

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

[lucier at math dot purdue dot edu]

------- Comment #16 from lucier at math dot purdue dot edu  2006-09-21 14:38 -------
Subject: Re:  Found a problem with the JNI methods declared and implemented


On Sep 21, 2006, at 10:31 AM, ebotcazou at gcc dot gnu dot org wrote:

>> mkdir foo
>> cd foo
>> ../configure
>
> Beginner error I'm afraid. :-)  See http://gcc.gnu.org/install/ 
> configure.html

Eric, it is not forbidden to put objdir into srcdir.  It is not  
unsupported to do so.  Among the many bugs I've found in gcc build  
and configuration over the years, not one was due to this.

More and more bug reports are met with comments like "it works for  
me" (IWFM), which I don't find helpful.

Brad


-- 


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

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

[WILLIAMPAUL dot PHILIBERT at telus dot com]

------- Comment #17 from WILLIAMPAUL dot PHILIBERT at telus dot com  2006-09-21 14:49 -------
Subject: RE:  Found a problem with the JNI methods declared and implemented

Well the only way I had to compile GCC 4.1.1 under Solaris 9 and get rid of the
JNI methods error was to disable the test right in the source.



William Paul Philibert


-- 


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

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

[jblaine at mitre dot org]

------- Comment #18 from jblaine at mitre dot org  2006-09-21 16:04 -------
Not beginner error.  I just tried with my objdir completely outside the
srcdir and the error is the same.


-- 


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

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

[ebotcazou at gcc dot gnu dot org]

------- Comment #19 from ebotcazou at gcc dot gnu dot org  2006-09-21 16:09 -------
> Eric, it is not forbidden to put objdir into srcdir.  It is not  
> unsupported to do so.

Simply amazing...  Quoting http://gcc.gnu.org/install/configure.html:

"First, we highly recommend that GCC be built into a separate directory than
the sources which does not reside within the source tree. This is how we
generally build GCC; building where srcdir == objdir should still work, but
doesn't get extensive testing; building where objdir is a subdirectory of
srcdir is unsupported."

> Among the many bugs I've found in gcc build and configuration over the
> years, not one was due to this.

It may have been the hidden trigger of a bunch of them...

> More and more bug reports are met with comments like "it works for me"
> (IWFM), which I don't find helpful.

It's actually IWIYFTI (It Works If You Follow The Instructions).


-- 


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

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

[lucier at math dot purdue dot edu]

------- Comment #20 from lucier at math dot purdue dot edu  2006-09-21 16:22 -------
Subject: Re:  Found a problem with the JNI methods declared and implemented


On Sep 21, 2006, at 12:09 PM, ebotcazou at gcc dot gnu dot org wrote:

> building where objdir is a subdirectory of
> srcdir is unsupported."

I've followed the mail lists for years while this was debated; I  
don't think it's settled.  ("./configure; make" definitely isn't  
supported.)

>
>> Among the many bugs I've found in gcc build and configuration over  
>> the
>> years, not one was due to this.
>
> It may have been the hidden trigger of a bunch of them...

Ah, yes, the latent bug syndrome.  If you find it, it's your problem ...

>
>> More and more bug reports are met with comments like "it works for  
>> me"
>> (IWFM), which I don't find helpful.
>
> It's actually IWIYFTI (It Works If You Follow The Instructions).

More actually it's "If I can find a way to criticize your bug report,  
I don't have to look for root causes".

This is a real bug.  See the message a few lines up.  I'm not saying  
it's *your* bug, but it's real.

Brad


-- 


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

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

[tromey at gcc dot gnu dot org]

------- Comment #21 from tromey at gcc dot gnu dot org  2006-09-21 17:02 -------
I think the best solution is to disable the check.
We don't need it and making it always be correct seems like a pain.


-- 


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

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

[ebotcazou at gcc dot gnu dot org]

------- Comment #22 from ebotcazou at gcc dot gnu dot org  2006-09-21 17:57 -------
> I've followed the mail lists for years while this was debated; I  
> don't think it's settled.  ("./configure; make" definitely isn't  
> supported.)

Tempus fugit. :-)

Index: ChangeLog
===================================================================
--- ChangeLog   (revision 41976)
+++ ChangeLog   (revision 41977)
@@ -1,3 +1,8 @@
+2001-05-12  Dean Wakerley  <dean@wakerley.com>
+
+       * doc/install.texi: New file. Converted to texinfo from the HTML
+       documentation in wwwdocs/htdocs/install.

41977 gerald First, we @strong{highly} recommend that GCC be built into a
41977 gerald separate directory than the sources which does @strong{not} reside
41977 gerald within the source tree.  This is how we generally build GCC;
building
41977 gerald where @emph{srcdir} == @emph{objdir} should still work, but
doesn't
41977 gerald get extensive testing; building where @emph{objdir} is a
subdirectory
41977 gerald of @emph{srcdir} is unsupported.

> Ah, yes, the latent bug syndrome.  If you find it, it's your problem ...

Correction: if you don't read the doc, ...

> More actually it's "If I can find a way to criticize your bug report,  

We strive to document every single step of the configure and build procedure,
every single bug we run into on exotic platforms and every single workaround
we find.  I think it's fair to expect the user to do us the favour of reading
the documentation before reporting a problem.


-- 


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

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

[rob1weld at aol dot com]

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

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

[Riot dot Nrrrd dot Bugzilla at isolar dot DynDNS dot ORG]

------- Comment #24 from Riot dot Nrrrd dot Bugzilla at isolar dot DynDNS dot ORG  2008-07-24 01:58 -------
(In reply to comment #0)
> When I do make a gmake bootstrap of GCC 4.1.1 I have the following output:
> 
> gmake[9]: Entering directory
> `/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava/classpath/native/jni'
> cd /opt/local/src/gcc-4.1.1/libjava/classpath && /bin/ksh
> ./scripts/check_jni_methods.sh
> Found a problem with the JNI methods declared and implemented.
> (-) missing in implementation, (+) missing in header files
> -Java_gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice_close_1
> -Java_gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice_open_1
> gmake[9]: *** [all-local] Error 1
> gmake[9]: Leaving directory
> `/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava/classpath/native/jni'
> gmake[8]: *** [all-recursive] Error 1
> gmake[8]: Leaving directory
> `/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava/classpath/native/jni'
> gmake[7]: *** [all-recursive] Error 1
> gmake[7]: Leaving directory
> `/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava/classpath/native'
> gmake[6]: *** [all-recursive] Error 1
> gmake[6]: Leaving directory
> `/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava/classpath'
> gmake[5]: *** [all-recursive] Error 1
> gmake[5]: Leaving directory
> `/opt/local/src/gcc-obj/sparc-sun-solaris2.9/sparcv9/libjava'
> gmake[4]: *** [multi-do] Error 1
> gmake[4]: Leaving directory
> `/opt/local/src/gcc-obj/sparc-sun-solaris2.9/libjava'
> gmake[3]: *** [all-multi] Error 2
> gmake[3]: Leaving directory
> `/opt/local/src/gcc-obj/sparc-sun-solaris2.9/libjava'
> gmake[2]: *** [all-target-libjava] Error 2
> gmake[2]: Leaving directory `/opt/local/src/gcc-obj'
> gmake[1]: *** [all] Error 2
> gmake[1]: Leaving directory `/opt/local/src/gcc-obj'
> gmake: *** [bootstrap] Error 2
> 
> I have the same problem whether I am use /usr/bin/ccs/ld&as of gnu component.
> 
> The CONFIG_SHELL is /bin/ksh
> 
> Compiling on a SunFire V240 with Solaris 9
> 
> I am in gcc-obj directory which is not the source dir.

Update:

I'm having the same exact problem with bootstrapping 4.3.1 on Solaris 9 on a
SunFire V240.  I am not having CONFIG_SHELL set to "/bin/ksh" or anything else,
but I doubt that matters here.


-- 

Riot dot Nrrrd dot Bugzilla at isolar dot DynDNS dot ORG changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Riot dot Nrrrd dot Bugzilla
                   |                            |at isolar dot DynDNS dot ORG


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