libtool linking libgcj

[David Daney]

Bryce McKinlay wrote:

> On Tuesday, Sep 30, 2003, at 04:22 Pacific/Auckland, Andrew Haley wrote:
>
>> When linking libgcj, the libtool shell script consumes more than two
>> minutes of CPU time on my box, a 1200MHz processor.  This is a lot
>> more time than the link itself takes.
>
>
> Yes, its getting pretty ridiculous. We need to get rid of libtool. We 
> should build libgcj package-by-package, with the option of either 
> building each package with a single compiler command, or multiple 
> compiler invocations linked into a package .o with "ld -r". This 
> strategy will make the command line length problems a non-issue, and 
> incremental rebuilds should be fast.

On some platforms (MIPS o32) it has been said that this type of 
incremental linking (and the current way that libtool does it also) is 
the cause of GOT overflow problems, for which the only known work around 
is to enable a large GOT which results in slower code.

My $0.02 is that perhaps libgcj should be broken into several separate 
shared objects.

Another thought is to add an option to ld to pass a "file list file" 
similar to the @filelist that the M$ linker has (or at least used to 
have).  Those stuck with older versions of ld or non gnu-ld would still 
have to suffer through the libtool slowness.

David Daney.