This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Enhancement Request
- From: Tom Tromey <tromey at redhat dot com>
- To: Glenn Chambers <gchamber at bright dot net>
- Cc: Jeff Sturm <jsturm at one-point dot com>, <java at gcc dot gnu dot org>
- Date: 31 Dec 2002 01:30:39 -0700
- Subject: Re: Enhancement Request
- References: <BE3C6578-193F-11D7-86A9-000393100C94@bright.net>
- Reply-to: tromey at redhat dot com
>>>>> "Glenn" == Glenn Chambers <gchamber@bright.net> writes:
Glenn> If the libffi and 'gcj/gc.h' files existed, I'd hack the
Glenn> configuration of Portable.NET to use the installed files
Glenn> instead of its own, thus ensuring consistency.
I looked at this issue some more tonight.
For the GC it probably makes more sense for Portable.NET to use the
upstream version. It has all the configure bits in it, and I know
somebody has upgraded it to use autoconf 2.5x (something we still
can't use in our tree). I have a patch to disable installation of the
headers which I'll check in soon.
For libffi, I think it would make the most sense for somebody to do an
independent release of the library. Actually, it could use some
install attention in general; for instance right now the installed
fficonfig.h defines stuff without an `FFI_' prefix -- history has
shown that this leads to problems. Unfortunately fixing this probably
means touching code all over the place.
Also we build libffi as a convenience library. Will this cause
problems for you? If so, I don't know if there is a way around it in
our tree, since we probably can't build it both ways at once.
Anyway, once a small bug in the top-level Makefile is fixed, we'll
still be installing libffi, warts and all. I'm of two minds on this,
but I for inertia carries the day.
Tom