libjava "make install" is broken again

[Alexandre Oliva]

On Mar  3, 2002, Bryce McKinlay <bryce@waitaki.otago.ac.nz> wrote:

> 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.

Well, there's nothing stopping us from setting boehm-gc up like
libltdl, that offers configure-time options for being built as a
convenience library, a stand-alone library or both.  Ideally, such
libraries should have different names, which is precisely the best
arrangement for us: libgcjgc for the convenience-library version and
say libboehmgc for the installable version.  Whether to build and
install each one by default is something we still have to debate and
make a decision, but it's obviously doable and beneficial for libjava
at least in the short term.

> It is certainly wrong for gcj to dynamically link binaries directly
> against libgcjgc - which is what is done currently.

This is only wrong if you assume the dynamic linker could resolve
dependencies of shared libraries by itself.  This is only the case on
a few platforms that support shared libraries.  Others will report
missing symbols at link time unless you explicitly specify dependent
libraries when linking the main program (even though the programs
would work just fine), and others simply cannot record inter-library
dependencies.  I agree it would be nice to omit the explicit
dependencies when possible, though, but libtool doesn't know when it's
possible to do so at this time, since it was never regarded as a
sufficiently important problem to deserve attention.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer