Re: DataInputStream changes...

[Brian Jones]

Bryce McKinlay <address@hidden> writes:

> Brian Jones wrote:
> 
> > I have noticed that the recent change to DataInputStream has broken
> > RandomAccessFile in Classpath.  Will it be long before this is fixed?
> > Trying to determine if I should try my changes against 0.01 rather
> > than against CVS before checking them in.
> 
> Hi Brian,
> 
> I apologise for the breakage. I have a fix for this, but have been
> trying to set up a build environment so that I can easily test my
> changes for build breakage in the future. Unfortunately, I haven't
> had much success so far as there seems to be multiple problems with
> the classpath build...
> 
> 1. configure looks for a 'japhar-config' file and aborts if it cant
> find it. There doesn't seem to be a way around this, as it tries to
> find the file even if "--without-japhar" is specified. I hacked my
> way around this by removing all the japhar detection stuff from
> configure.in. (Obviously the easy fix for these problems is just to
> give in and install japhar, but I couldn't get japhar to build
> either, it was a bad night ;-)

After taking a look, I think you'll need Japhar installed to compile.
This mostly has to do with not wanting people to try compiling for
something we don't support unless they know what they are doing.

> 2. cant build in a subdirectory of the build tree, srcdir must be
> same as builddir. This seems to be because certain parts of the
> Makefiles are looking for things in top_srcdir when they should be
> looking in top_builddir (or vice-versa?). Got around this by
> building in the srcdir, no biggie.

If you'd like to fix this, feel free to do so.  I don't think we have
a good reason to work on it at the moment though.
 
> 3. Default build tries to build things that simply cannot compile,
> such as java/awt (theres no Event.java, so it can't possibly work,
> right?). I had to edit lib/standard.omit and add java/awt/* and
> java/applet/* to get around this.

To get around this problem I compile against Sun's classes.zip or even
Kaffe's klasses.jar or whatever it is called...
 
> 4. (and this is the problem that I'm stuck on) jikes doesn't seem to
> believe that files in java/lang and vm/reference/java/lang are
> actually in the same package. ie: when its building java/lang and
> looks for Runtime.java, it doesn't "find" it in
> vm/reference/java/lang even though vm/reference is on the classpath.
> What I can't understand is why japhar's implementation of these
> files wouldn't also suffer from this problem - or does the japhar
> build symlink them or copy its files into a single directory? or
> what?

Interesting.  The configure script symbolically links vm/reference to
vm/current.  The lib/Makefile.am should be appropriate at that point
to compile things.
 
> Can anyone successfully build classpath without having japhar
> installed? Does anyone build the files in vm/reference?

Without Japhar, probably not.  I actually installed gcj recently to
try building libgcj from CVS but it failed to compile libgcj so I've
not worked on supporting that yet.  The compiler got confused and gave
up even though it gave me an error message indicating it knew where a
class was... so I guess I'm struggling as much there as you are here.

I do build the files in vm/reference, but those are only useful for
Japhar.

Brian
-- 
Brian Jones <address@hidden>