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

[Mohan Embar]

Hi Bryce,

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

Thanks for looking at this.

Do we mandate GNU binutils for libgcj? (I thought we didn't.) If not,
is -r supported by all UNIX-like versions of ld? (Don't know much about
this subject.) If not, how would you propose getting around this?

Can you also remind we what outstanding issues are stopping our migration
to the latest automake / autoconf? This has been touched on numerous times,
but I haven't been following the discussion closely or tracking what might
have improved since this was last brought up.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/