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: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: 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: Tue, 05 Mar 2002 12:08:13 +1300
- Subject: Re: libjava "make install" is broken again
- References: <40700B4C02ABD5119F000090278766443BF02A@hplex1.hpl.hp.com>
Boehm, Hans wrote:
>(So would changing the front end to call into
>the GC directly. But that's harder, less clean, and hasn't happened
>yet. It would shorten the allocation path still more.)
>
>>It is certainly wrong for gcj to dynamically link binaries directly
>>against libgcjgc - which is what is done currently.
>>
>Unless we generate code that calls into it directly?
>
That would be good, but I'd rather that the GC defined _Jv_AllocObj()
rather than have the front end generate boehm-gc specific calls. That
way it is possible to plug an alternative GC into libgcj without
recompiling the applications, at least in the binary compatibility mode
where the GC descriptors are generated at runtime.
regards
Bryce.