This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libjava "make install" is broken again
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>, "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: Fri, 15 Mar 2002 18:05:45 -0500
- Subject: Re: libjava "make install" is broken again
- References: <40700B4C02ABD5119F000090278766443BF02A@hplex1.hpl.hp.com> <3C83FE5D.7070404@waitaki.otago.ac.nz> <87k7sdv25j.fsf@creche.redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Mar 15, 2002 at 04:31:36PM -0700, Tom Tromey wrote:
> >>>>> "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?
Yes, especially if libgcj is versioned and all the GC symbols are local...
Jakub