[gcj trunk / gnu-classpath] String.format(...) undefined

[Mark Wielaard]

Hi Hanno,

On Sun, 2007-02-18 at 14:40 +0100, Hanno Meyer-Thurow wrote:
> On Sun, 18 Feb 2007 12:54:59 +0000
> Andrew Haley <aph@redhat.com> wrote:
> 
> >  /mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070216/work/gcc-4.3-20070216/libjava/java/lang/natString.cc:710: error: no 'jint java::lang::String::nativeCompareTo(java::lang::String*)' member function declared in class 'java::lang::String'
> 
> > You didn't rebuild the header file for String.h ?
> 
> Nope. Plain gcj-4.3.20070216 snapshot with patch of Mark.
> How do I regenerate the header?
> ___
> Btw, kind of off-topic, though, I wonder if any .java files are compiled to
> .class in trunk. Since there are .class files already. So, if I patched some
> .java files in libjava or libjava/classpath would a normal gcj build take the
> changes?

Thanks for trying out the patch. Sorry it wasn't obvious that the above
to issues are one and the same. See the libjava/HACKING file. It
explains setting up your build so that you can configure with
--enable-java-maintainer-mode. With that enabled .h and .class files get
regenerated inside the source dir when the .java source files change.

By default this is off, since it might be that someone doesn't have a
ecj1 and/or gjavah binary to start the bootstrap (see the
libjava/HACKING file again for hints how to get both if you don't have a
recent gcc/gcj install around).

Cheers,

Mark

> Well, I see that the shipped gnu classpath is not compiled to .class files
> now. Although, if ecj supplied it would be nice to compile .java to .class.
> Like gcj compiles gnu classpath in gcj-4.2.
> 
> 
> Regards,
> Hanno
>