This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Build failure with the 0.98 merge
- From: "Andrew John Hughes" <gnu_andrew at member dot fsf dot org>
- To: "David Daney" <ddaney at avtrex dot com>
- Cc: "Tom Tromey" <tromey at redhat dot com>, java <java at gcc dot gnu dot org>
- Date: Wed, 3 Sep 2008 00:59:59 +0100
- Subject: Re: Build failure with the 0.98 merge
- References: <17c6771e0808201352p69c0264dm5afd1dabec872992@mail.gmail.com> <m3pro2jm63.fsf@fleche.redhat.com> <17c6771e0809021355p5d91191dhff40d701727c7382@mail.gmail.com> <48BDA955.5050305@avtrex.com>
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