Re: [JAVA,libtool] Big libjava is biiiig.

Hello Dave,

* Dave Korn wrote on Wed, May 06, 2009 at 06:09:05PM CEST:
> 
>   So I'm currently experimenting with a patch that adds a new option
> "--enable-libgcj-sublibs" in libjava/configure.ac.  I may need to add a
> dummy-link-and-relink stage to get the interdependencies working right, or I
> might have to hack something in libtool, but the basic approach of adding a
> bunch of extra libtool declarations based on $(filter)ing the full list of
> dependencies from the complete libgcj_la_LIBADD definition seemed a reasonable
> way to go:
> 
> +if BUILD_SUBLIBS
> +libgcj_gnu_la_LIBADD = $(filter gnu/%.lo,$(libgcj_la_LIBADD)) -L$(here)/.libs
> libgcj.la
> +libgcj_java_la_LIBADD = $(filter java/%.lo,$(libgcj_la_LIBADD))
> -L$(here)/.libs libgcj.la
> +libgcj_javax_la_LIBADD = $(filter javax/%.lo,$(libgcj_la_LIBADD))
> -L$(here)/.libs libgcj.la
> +libgcj_misc_la_LIBADD = $(filter-out gnu/%.lo java/%.lo
> javax/%.lo,$(libgcj_la_LIBADD)) -L$(here)/.libs libgcj.la
> +endif

I don't yet see why you would need any kind of libtool hacking.

I also don't see why the GCC tree *ever* uses -L$(something)/.libs in
directories where libtool is used.  Just specify in-tree library
dependencies as 'libgcj.la' and automake and libtool will do The Right
Thing.  You adding an explicit -L.libs can only lead to installed .la
files retaining paths to build tree locations.

> 1)  Would this be a reasonable approach, specifically i) in adding a configure
> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
> construct to crudely subdivide the libraries like this?

You are aware of the fact that it is part of the ABI in which of the
linked DLLs a given symbol was found, and any shuffling of that later
will break that ABI?

You also have to ensure that the sub libraries are self-contained, or at
least their interdependencies form a directed non-cyclic graph (or you
will need very ugly hacks on w32).

> 2)  Given that there's a bit of a logjam upstream, and not likely to be
> another libtool release betwen now and the end of stage1,

What makes you think so?  There is a backlog of some patches, but that
doesn't mean
- important patches won't go in,
- GCC can't update to a newer unreleased Libtool version; it has done
  this several times, and it does not require the GCC developers to
  upgrade their build tools.

> would it be
> acceptable (in general) to hack on our in-tree libtool first and send patches
> upstream second (thus still avoiding any potential future merge lossage)?

I don't see a reason for that in your message.  Do you have other
reasons for suggesting this?

Cheers,
Ralf