Build failure with the 0.98 merge

Build failure with the 0.98 merge

[Andrew John Hughes]

Hi all,

I'm getting a build error when trying to compile the version of GCJ
merged with Classpath 0.98:

In file included from
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/interpret.cc:25:
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:97:
error: 'java::lang::AbstractStringBuffer*
java::lang::StringBuffer::StringBuffer$append(jchar)' cannot be
overloaded
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:38:
error: with 'virtual java::lang::StringBuffer*
java::lang::StringBuffer::StringBuffer$append(jchar)'
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:100:
error: 'java::lang::AbstractStringBuffer*
java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
jint, jint)' cannot be overloaded
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:36:
error: with 'java::lang::StringBuffer*
java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
jint, jint)'
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:102:
error: 'java::lang::AbstractStringBuffer*
java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
cannot be overloaded
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:35:
error: with 'java::lang::StringBuffer*
java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
make[3]: *** [interpret.lo] Error 1

Is there an issue with gcj and the use of covariant return types from 1.5?

The methods in question are StringBuffer.append(char),
StringBuffer.append(CharSequence,int,int) and
StringBuffer.append(CharSequence). All return a StirngBuffer and
override methods with the same signature but a return type of
AbstractStringBuffer in AbstractStringBuffer.

Cheers,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: Build failure with the 0.98 merge

[Andrew Haley]

Andrew John Hughes wrote:
> Hi all,
> 
> I'm getting a build error when trying to compile the version of GCJ
> merged with Classpath 0.98:

Is this when building gcc itself, or a local merge, i.e. can I look
at this for myself?

> In file included from
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/interpret.cc:25:
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:97:
> error: 'java::lang::AbstractStringBuffer*
> java::lang::StringBuffer::StringBuffer$append(jchar)' cannot be
> overloaded
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:38:
> error: with 'virtual java::lang::StringBuffer*
> java::lang::StringBuffer::StringBuffer$append(jchar)'
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:100:
> error: 'java::lang::AbstractStringBuffer*
> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
> jint, jint)' cannot be overloaded
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:36:
> error: with 'java::lang::StringBuffer*
> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
> jint, jint)'
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:102:
> error: 'java::lang::AbstractStringBuffer*
> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
> cannot be overloaded
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:35:
> error: with 'java::lang::StringBuffer*
> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
> make[3]: *** [interpret.lo] Error 1
> 
> Is there an issue with gcj and the use of covariant return types from 1.5?
> 
> The methods in question are StringBuffer.append(char),
> StringBuffer.append(CharSequence,int,int) and
> StringBuffer.append(CharSequence). All return a StirngBuffer and
> override methods with the same signature but a return type of
> AbstractStringBuffer in AbstractStringBuffer.
> 
> Cheers,

Re: Build failure with the 0.98 merge

[Andrew John Hughes]

2008/8/21 Andrew Haley <aph@redhat.com>:
> Andrew John Hughes wrote:
>> Hi all,
>>
>> I'm getting a build error when trying to compile the version of GCJ
>> merged with Classpath 0.98:
>
> Is this when building gcc itself, or a local merge, i.e. can I look
> at this for myself?
>

Sorry, should have been clearer; this is the current state of
branches/gcj/classpath-098-merge-branch, so
yes you can take a look :)

>> In file included from
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/interpret.cc:25:
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:97:
>> error: 'java::lang::AbstractStringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(jchar)' cannot be
>> overloaded
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:38:
>> error: with 'virtual java::lang::StringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(jchar)'
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:100:
>> error: 'java::lang::AbstractStringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
>> jint, jint)' cannot be overloaded
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:36:
>> error: with 'java::lang::StringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
>> jint, jint)'
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:102:
>> error: 'java::lang::AbstractStringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
>> cannot be overloaded
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:35:
>> error: with 'java::lang::StringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
>> make[3]: *** [interpret.lo] Error 1
>>
>> Is there an issue with gcj and the use of covariant return types from 1.5?
>>
>> The methods in question are StringBuffer.append(char),
>> StringBuffer.append(CharSequence,int,int) and
>> StringBuffer.append(CharSequence). All return a StirngBuffer and
>> override methods with the same signature but a return type of
>> AbstractStringBuffer in AbstractStringBuffer.
>>
>> Cheers,
>
>



-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: Build failure with the 0.98 merge

[David Daney]

Andrew John Hughes wrote:
> Hi all,
> 
> I'm getting a build error when trying to compile the version of GCJ
> merged with Classpath 0.98:
> 
> In file included from
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/interpret.cc:25:
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:97:
> error: 'java::lang::AbstractStringBuffer*
> java::lang::StringBuffer::StringBuffer$append(jchar)' cannot be
> overloaded
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:38:
> error: with 'virtual java::lang::StringBuffer*
> java::lang::StringBuffer::StringBuffer$append(jchar)'
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:100:
> error: 'java::lang::AbstractStringBuffer*
> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
> jint, jint)' cannot be overloaded
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:36:
> error: with 'java::lang::StringBuffer*
> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
> jint, jint)'
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:102:
> error: 'java::lang::AbstractStringBuffer*
> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
> cannot be overloaded
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:35:
> error: with 'java::lang::StringBuffer*
> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
> make[3]: *** [interpret.lo] Error 1
> 
> Is there an issue with gcj and the use of covariant return types from 1.5?
> 
> The methods in question are StringBuffer.append(char),
> StringBuffer.append(CharSequence,int,int) and
> StringBuffer.append(CharSequence). All return a StirngBuffer and
> override methods with the same signature but a return type of
> AbstractStringBuffer in AbstractStringBuffer.

From #gcj:

(09:49:57 AM) daney: You could keep the common code factored out, but just use different names for the methods.  Because the java code has to return the correct type and synchronize, there have to be little stub methods in the child class that return super.method().  Since we already have to have these little stubs, they might as well return super.otherMethod()

(09:50:40 AM) tromey: yeah

(09:50:44 AM) daney: That way the public methods would not have to override anything.

Re: Build failure with the 0.98 merge

[David Daney]

David Daney wrote:
> Andrew John Hughes wrote:
>> Hi all,
>>
>> I'm getting a build error when trying to compile the version of GCJ
>> merged with Classpath 0.98:
>>
>> In file included from
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/interpret.cc:25:
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:97: 
>>
>> error: 'java::lang::AbstractStringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(jchar)' cannot be
>> overloaded
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:38: 
>>
>> error: with 'virtual java::lang::StringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(jchar)'
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:100: 
>>
>> error: 'java::lang::AbstractStringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
>> jint, jint)' cannot be overloaded
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:36: 
>>
>> error: with 'java::lang::StringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*,
>> jint, jint)'
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:102: 
>>
>> error: 'java::lang::AbstractStringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
>> cannot be overloaded
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:35: 
>>
>> error: with 'java::lang::StringBuffer*
>> java::lang::StringBuffer::StringBuffer$append(java::lang::CharSequence*)'
>> make[3]: *** [interpret.lo] Error 1
>>
>> Is there an issue with gcj and the use of covariant return types from 
>> 1.5?
>>
>> The methods in question are StringBuffer.append(char),
>> StringBuffer.append(CharSequence,int,int) and
>> StringBuffer.append(CharSequence). All return a StirngBuffer and
>> override methods with the same signature but a return type of
>> AbstractStringBuffer in AbstractStringBuffer.
> 
>  From #gcj:
> 
> (09:49:57 AM) daney: You could keep the common code factored out, but 
> just use different names for the methods.  Because the java code has to 
> return the correct type and synchronize, there have to be little stub 
> methods in the child class that return super.method().  Since we already 
> have to have these little stubs, they might as well return 
> super.otherMethod()
> 
> (09:50:40 AM) tromey: yeah
> 
> (09:50:44 AM) daney: That way the public methods would not have to 
> override anything.

More Ideas...


(09:57:21 AM) tromey: ISTR some special code in the new gcjh for this stuff
(09:57:22 AM) tromey: hmm
(10:02:45 AM) daney: Any overridden method is declared to return the same type as the base class method?
(10:03:19 AM) daney: Something like that might work.
(10:04:14 AM) daney: I don't know if you would have to do anything for interfaces.
(10:04:50 AM) tromey: I'd have to look it up
(10:05:01 AM) tromey: whatever I did here required a lot of thought
(10:05:13 AM) tromey: to ensure myself that it was correct
(10:06:19 AM) daney: When building with -enable-java-maintainer-mode we use the system gjavah and not the one from the code being built, don't we?
(10:06:51 AM) tromey: yeah
(10:06:57 AM) tromey: I think so
(10:06:58 AM) daney: I wonder if that is his problem.

Re: Build failure with the 0.98 merge

[Tom Tromey]

>>>>> "Andrew" == Andrew John Hughes <gnu_andrew@member.fsf.org> writes:

Andrew> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:97:
Andrew> error: 'java::lang::AbstractStringBuffer*
Andrew> java::lang::StringBuffer::StringBuffer$append(jchar)' cannot be
Andrew> overloaded
Andrew> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:38:

Andrew> Is there an issue with gcj and the use of covariant return
Andrew> types from 1.5?

There shouldn't be.  javah has special code in it to rename bridge
method targets in this situation.

Looking at the header I see:

  ::java::lang::StringBuffer * StringBuffer$append(jchar);
  ::java::lang::Appendable * append(jchar);
  ::java::lang::AbstractStringBuffer * StringBuffer$append(jchar);

And looking at AbstractStringBuffer.h:

  virtual ::java::lang::AbstractStringBuffer * AbstractStringBuffer$append(jchar);
  virtual ::java::lang::Appendable * append(jchar);


So I think javah's bug is that it does not understand how bridge
methods might be inherited, and so it does not know rename targets
according to the class in the hierarchy where they first appeared.
IOW, that 3rd append method in StringBuffer.h should be named
AbstractStringBuffer$append.

Tom

Re: Build failure with the 0.98 merge

[Andrew John Hughes]

2008/8/21 Tom Tromey <tromey@redhat.com>:
>>>>>> "Andrew" == Andrew John Hughes <gnu_andrew@member.fsf.org> writes:
>
> Andrew> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:97:
> Andrew> error: 'java::lang::AbstractStringBuffer*
> Andrew> java::lang::StringBuffer::StringBuffer$append(jchar)' cannot be
> Andrew> overloaded
> Andrew> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:38:
>
> Andrew> Is there an issue with gcj and the use of covariant return
> Andrew> types from 1.5?
>
> There shouldn't be.  javah has special code in it to rename bridge
> method targets in this situation.
>
> Looking at the header I see:
>
>  ::java::lang::StringBuffer * StringBuffer$append(jchar);
>  ::java::lang::Appendable * append(jchar);
>  ::java::lang::AbstractStringBuffer * StringBuffer$append(jchar);
>
> And looking at AbstractStringBuffer.h:
>
>  virtual ::java::lang::AbstractStringBuffer * AbstractStringBuffer$append(jchar);
>  virtual ::java::lang::Appendable * append(jchar);
>
>
> So I think javah's bug is that it does not understand how bridge
> methods might be inherited, and so it does not know rename targets
> according to the class in the hierarchy where they first appeared.
> IOW, that 3rd append method in StringBuffer.h should be named
> AbstractStringBuffer$append.
>
> Tom
>

Changing that manually fixed the issue.  I'll look at patching gjavah
to do the right thing.

Continuing, I get more strange errors:

/home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:
In static member function 'static java::lang::Object*
gnu::gcj::util::Debug::getField(java::lang::Object*,
java::lang::reflect::Field*)':
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
error: expected type-specifier
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
error: cannot convert 'int*' to 'java::lang::Object*' in return
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
error: expected ';'
/home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
error: 'Double' is not a member of 'gnu::java::lang'

natDebug.cc hasn't changed; any idea what could be wrong here?

Thanks,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: Build failure with the 0.98 merge

[David Daney]

Andrew John Hughes wrote:
> 2008/8/21 Tom Tromey <tromey@redhat.com>:
>>>>>>> "Andrew" == Andrew John Hughes <gnu_andrew@member.fsf.org> writes:
>> Andrew> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:97:
>> Andrew> error: 'java::lang::AbstractStringBuffer*
>> Andrew> java::lang::StringBuffer::StringBuffer$append(jchar)' cannot be
>> Andrew> overloaded
>> Andrew> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:38:
>>
>> Andrew> Is there an issue with gcj and the use of covariant return
>> Andrew> types from 1.5?
>>
>> There shouldn't be.  javah has special code in it to rename bridge
>> method targets in this situation.
>>
>> Looking at the header I see:
>>
>>  ::java::lang::StringBuffer * StringBuffer$append(jchar);
>>  ::java::lang::Appendable * append(jchar);
>>  ::java::lang::AbstractStringBuffer * StringBuffer$append(jchar);
>>
>> And looking at AbstractStringBuffer.h:
>>
>>  virtual ::java::lang::AbstractStringBuffer * AbstractStringBuffer$append(jchar);
>>  virtual ::java::lang::Appendable * append(jchar);
>>
>>
>> So I think javah's bug is that it does not understand how bridge
>> methods might be inherited, and so it does not know rename targets
>> according to the class in the hierarchy where they first appeared.
>> IOW, that 3rd append method in StringBuffer.h should be named
>> AbstractStringBuffer$append.
>>
>> Tom
>>
> 
> Changing that manually fixed the issue.  I'll look at patching gjavah
> to do the right thing.
> 
> Continuing, I get more strange errors:
> 
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:
> In static member function 'static java::lang::Object*
> gnu::gcj::util::Debug::getField(java::lang::Object*,
> java::lang::reflect::Field*)':
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
> error: expected type-specifier
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
> error: cannot convert 'int*' to 'java::lang::Object*' in return
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
> error: expected ';'
> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
> error: 'Double' is not a member of 'gnu::java::lang'
> 
> natDebug.cc hasn't changed; any idea what could be wrong here?
> 

Some type definition missing from some header file.

I would look at the preprocessed source for clues.

David Daney

Re: Build failure with the 0.98 merge

[Andrew John Hughes]

2008/9/2 David Daney <ddaney@avtrex.com>:
> Andrew John Hughes wrote:
>>
>> 2008/8/21 Tom Tromey <tromey@redhat.com>:
>>>>>>>>
>>>>>>>> "Andrew" == Andrew John Hughes <gnu_andrew@member.fsf.org> writes:
>>>
>>> Andrew>
>>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:97:
>>> Andrew> error: 'java::lang::AbstractStringBuffer*
>>> Andrew> java::lang::StringBuffer::StringBuffer$append(jchar)' cannot be
>>> Andrew> overloaded
>>> Andrew>
>>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/java/lang/StringBuffer.h:38:
>>>
>>> Andrew> Is there an issue with gcj and the use of covariant return
>>> Andrew> types from 1.5?
>>>
>>> There shouldn't be.  javah has special code in it to rename bridge
>>> method targets in this situation.
>>>
>>> Looking at the header I see:
>>>
>>>  ::java::lang::StringBuffer * StringBuffer$append(jchar);
>>>  ::java::lang::Appendable * append(jchar);
>>>  ::java::lang::AbstractStringBuffer * StringBuffer$append(jchar);
>>>
>>> And looking at AbstractStringBuffer.h:
>>>
>>>  virtual ::java::lang::AbstractStringBuffer *
>>> AbstractStringBuffer$append(jchar);
>>>  virtual ::java::lang::Appendable * append(jchar);
>>>
>>>
>>> So I think javah's bug is that it does not understand how bridge
>>> methods might be inherited, and so it does not know rename targets
>>> according to the class in the hierarchy where they first appeared.
>>> IOW, that 3rd append method in StringBuffer.h should be named
>>> AbstractStringBuffer$append.
>>>
>>> Tom
>>>
>>
>> Changing that manually fixed the issue.  I'll look at patching gjavah
>> to do the right thing.
>>
>> Continuing, I get more strange errors:
>>
>>
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:
>> In static member function 'static java::lang::Object*
>> gnu::gcj::util::Debug::getField(java::lang::Object*,
>> java::lang::reflect::Field*)':
>>
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
>> error: expected type-specifier
>>
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
>> error: cannot convert 'int*' to 'java::lang::Object*' in return
>>
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
>> error: expected ';'
>>
>> /home/andrew/projects/classpath/gcj/sources/gcc/libjava/gnu/gcj/util/natDebug.cc:73:
>> error: 'Double' is not a member of 'gnu::java::lang'
>>
>> natDebug.cc hasn't changed; any idea what could be wrong here?
>>
>
> Some type definition missing from some header file.
>
> I would look at the preprocessed source for clues.
>
> David Daney
>

  if (type == & _Jv_doubleClass)
    return new java::lang::Double (* (jdouble*) addr);

which looks a little odd to me.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8