Re: Build failure with the 0.98 merge

"Andrew John Hughes" <[email protected]>
Newsgroups gmane.comp.gcc.java.devel
Message-ID <[email protected]>
2008/9/2 David Daney <[email protected]>:
> Andrew John Hughes wrote:
>>
>> 2008/8/21 Tom Tromey <[email protected]>:
>>>>>>>>
>>>>>>>> "Andrew" == Andrew John Hughes <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.