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