Trouble building gcj 4.8.1

[Andïï]

On 25 June 2013 09:21, Andrew Haley <aph@redhat.com> wrote:
> On 06/25/2013 03:15 PM, Mike Hearn wrote:
>>> I'm trying to find out what you want to do to java.lang.String.  Tell me
>>> that, and we'll take it from there.
>>
>> At the moment, supporting the methods that take java.nio.Charset. I'm
>> going to try and just hack it up with something like this:
>>
>>   public String(byte[] data, int offset, int count, Charset encoding)
>>     throws UnsupportedEncodingException
>>   {
>>     init (data, offset, count, encoding.name());
>>   }
>>
>> and then the same for getBytes().
>
> OK.  I think you can just add those methods.
>
>> But in general I anticipate that I'll continue to hit stubs or quirks
>> in classpath so I'm trying to figure out how best to reach my goal,
>> which will likely involve fixing up various things along the way. For
>> instance, my first yak-shaving goal is to run the test suite for the
>> core library of this app and then hack/fix until all the tests pass.
>
> In general, we follow Classpath except for a few core classes -- and
> String is one of those.  Major hacking on core classes requires compiler
> changes, so I strongly recommend you don't do that.  For example, better
> not add any fields.  But in general for almost the whole class library
> you won't have so much trouble.
>
> Andrew.
>
>

>From what I recall, I tried to update gcj's copy of java.lang.String a
few years ago -
I have a feeling it may have even been for these methods - and wasn't
very successful.
I think the result is still tucked away in gcc's Bugzilla.  The
structure is quite different
from Classpath's and specific to how gcj works internally, as String
has to work at both
the Java and native level.

Silly question, but if Classpath has what you want already, why not
just hook it up with
a VM like CACAO that uses it directly?  It would probably take a
fraction of the time it
takes to even build gcj.  Why do you specifically want gcj?
--
Andii :-)