RE: libjava "make install" is broken again

["Boehm, Hans" <hans_boehm at hp dot com>]

> -----Original Message-----
> From: Bryce McKinlay [mailto:bryce@waitaki.otago.ac.nz]
> 
> Jeff Sturm wrote:
> 
> >One workaround is to forget about libgcjgc.so and libzgcj.so 
> and link them
> >as convenience libraries instead.  I'm not sure why we have 
> these; at one
> >time it may have seemed feasible to have pluggable GC but it 
> certainly
> >isn't now.
> >
> 
> I agree. The only argument against doing that is that is that 
> it would 
> be nice to have boehm-gc installed as a separate .so that can 
> be used by 
> random non-Java programs. I know Hans has been working 
> towards that by 
> making most of the compile-time flags that used to enable 
> specific GCJ 
> support into runtime options. 
I think there are some conflicting goals here, and I'm not sure what
the right answer is.

The other side of the argument here is that getting rid of cross-dl
calls in the allocation path is a very good thing.  I can't think of
a good way to get rid of them all.  If I understand correctly, then
linking against the GC as a convenience library would get rid of one
of those immediately.  (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?

Hans