Build failure with the 0.98 merge

Andrew John Hughes gnu_andrew@member.fsf.org
Wed Sep 3 00:01:00 GMT 2008


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


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /