libtool linking libgcj

Mon Sep 29 23:15:00 GMT 2003

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.