This is the mail archive of the
mailing list for the GCC project.
Re: [JAVA,libtool] Big libjava is biiiig.
- From: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- To: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- Cc: java at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Wed, 6 May 2009 18:14:19 +0200
- Subject: Re: [JAVA,libtool] Big libjava is biiiig.
- References: <4A01B55C.email@example.com> <4A01B621.firstname.lastname@example.org>
* 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_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
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
- 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?