[MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C

[Bryce McKinlay]

On Dec 3, 2003, at 10:54 PM, Mohan Embar wrote:

> Tonight I scratched an itch that I've been wanting to scratch for 
> almost
> a year. And it felt nice.

Yeah, this itch is not uncommon. libgcj needs to (re)build faster.

> I wanted to see how much faster the libgcj build would go if I took
> libtool out of the picture for some of the pieces.

Quite a lot, I'd imagine. Using the latest CVS binutils helps too, to 
speed up the final link.

> After the configure process and compiling of the initial classfiles
> (using --enable-libgcj-multifile to do these all at once, of course)
> and .cc files, the build kicks into high gear. I watched the entire
> build in fascination the first time around, but didn't do any timings.
> I think it screams, but would be interested in observations from
> others.
>
> How does this sound? For me, it's so far out that there must be
> something wrong with my approach, but it's pretty cool and I'm
> having fun.

Well its a nice experiment, but probably a more compicated solution 
than we need. My preferred approach is just to rip out libtool 
entirely. This will mean slightly more platform-specific configuration 
is required, but overall, things should be simpler.

What I'd like is to write a new makefile, using the latest 
autoconf/automake, which: a) doesn't use libtool, and b) incrementally 
links each java package with ld -r. The ld -r approach means that the 
final link consists of linking a small number of large .o files instead 
of a large number of small ones, which should be a lot faster. This 
approach also stops it from tripping over command-line length limits, 
and could perhaps later be extended to do something like 
--enable-libgcj-multifile but for .o files.

Michael K and Thomas F have both expressed interest in working on this 
stuff, I don't know if they've made any progress.

Regards

Bryce.