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
