This is the mail archive of the
mailing list for the Java project.
Re: cannot build libjava/gnu/gcj/xlib/natClip.cc
- To: Bryce McKinlay <bryce at albatross dot co dot nz>
- Subject: Re: cannot build libjava/gnu/gcj/xlib/natClip.cc
- From: Per Bothner <per at bothner dot com>
- Date: 01 Jan 2001 19:22:45 -0800
- Cc: java-discuss at sources dot redhat dot com
- References: <email@example.com><3A4FC13C.755758CB@albatross.co.nz> <firstname.lastname@example.org><3A512F26.5DAD2970@albatross.co.nz>
Bryce McKinlay <email@example.com> writes:
> RawData works, however actual cases where it is useful dont seem to
> be all that common. If its our code thats doing the allocating, it
> is easier to use _Jv_AllocBytes and disguise the native data in an
> Object field. If we keep a pointer to something allocated with
> malloc, the GC will just ignore it anyway (but it is nicer to use a
> RawData just to make it obvious that the field shouldn't be touched
> from Java code).
We should be using RawData for such fields in case we ever make
a non-conserveative GC and option. This would require making G++
as well as Gcj GC-aware, so it is not likely to happen anytime soon.
Still, as soon as somebody does implement a precise GC then all
places that use regular Object fields to point to malloc'd data
are likely to cause crashes, so need to be fixed. Might as well
use RawData now.
> > /home/bothner/GNU/egcs/configure --enable-threads=posix --prefix=/home/bothner/GNU/linux --enable-shared --enable-languages=c++,java --disable-new-gxx-abi
> > make bootstrap
> > make
> Hmm. The only difference here is that I don't do a "make bootstrap".
Well, that is what the build instructions say to do.
See http://sources.redhat.com/java/build-snapshot.html .
> Can you figure out why [xxx] doesnt work for you?
I'll take a look.