This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: libjava "make install" is broken again
- From: Tom Tromey <tromey at redhat dot com>
- To: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- Cc: "Boehm, Hans" <hans_boehm at hp dot com>, Jeff Sturm <jsturm at one-point dot com>, Alexandre Oliva <aoliva at redhat dot com>, java-patches at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: 15 Mar 2002 16:31:36 -0700
- Subject: Re: libjava "make install" is broken again
- References: <40700B4C02ABD5119F000090278766443BF02A@hplex1.hpl.hp.com> <3C83FE5D.7070404@waitaki.otago.ac.nz>
- Reply-to: tromey at redhat dot com
>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
[ quasi-old email ]
Bryce> That would be good, but I'd rather that the GC defined
Bryce> _Jv_AllocObj() rather than have the front end generate boehm-gc
Bryce> specific calls. That way it is possible to plug an alternative
Bryce> GC into libgcj without recompiling the applications, at least
Bryce> in the binary compatibility mode where the GC descriptors are
Bryce> generated at runtime.
Will we ever want to build against a generic version of the Boehm GC?
If not I guess we could easily hack the GC build to export
_Jv_AllocObj. We could even do this with a -D option somewhere so we
only touch the configury and not the source.
Otherwise, maybe there's a way to define one symbol as an alias for
another.
My guess is we should do #1 and simply have the GC (and zlib) be built
as convenience libraries and pulled into libgcj. That should help
performance, right?
Tom