Re: make dist fixes

[Eric Blake]

Keep in mind that a workaround for this is to explicitly qualify the
method with the desired class (ie. the one where the method is actually
defined).

In other words, instead of
  Encoder8859_1.loadTable()
in the source code, use
  EncoderEightBitLookup.loadTable()

The only problem I see with this approach is if EncoderEightBitLookup is
not accessible when Encoder8859_1 is.  Then an alternative workaround
would be to modify Encoder8859_1 by adding this method:
  public static void loadTable() { super.loadTable(); }

I'm not familiar with the ORP code, but these workarounds shouldn't be
too hard.

Do you want me to file a PR for the gcc bug?  I've yet to get a working
compile of gcj on my cygwin box, so I'm not sure how well I would do on
bug reporting.

Mark Wielaard wrote:
> 
> That (and the example) seems to make sense. But it also means that we
> don't have one bug in jikes, but two bugs, one in ORP and one in gcj
> byte code generation. Sigh.
> 
> That basicly means we don't recommend jikes 1.15a for this Classpath
> release and ORP 1.0.9, or we wait for a new ORP release with a fix.
> Hmmmm. I would opt for releasing now and adding a note about this
> problem (with newer versions of jikes and ORP) to the README/INSTALL
> file. Or we could try to produce a patch for ORP, but I am not sure that
> is very easy.
> 
> Cheers,
> 
> Mark

-- 
This signature intentionally left boring.

Eric Blake             address@hidden
  BYU student, free software programmer