Re: libtool linking libgcj

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

On Tuesday, Sep 30, 2003, at 10:50 Pacific/Auckland, David Daney wrote:

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

Under the new BC-ABI libgcj should have a much smaller GOT, so I don't 
think this will be an issue. Besides, why should the way you link 
affect the final GOT size? If it does, it sounds like a linker bug to 
me.

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

Its cleaner to have a single libgcj.so. Also, the total size of the 
runtime will be smaller with a single shared library due to 
constant/string merging.

Regards

Bryce.