Lib change leads to larger executables

[Sean Kelly]

John Reimer wrote:
> On Wed, 21 Feb 2007 16:12:10 -0800, Walter Bright wrote:
> 
>> Derek Parnell wrote:
>>>> Most of the complexity in a linker stems from:
>>>> 1) trying to make it fast
>>> How fast is fast enough?
>> It's never fast enough. I know a fellow who made his fortune just 
>> writing a faster linker than MS-LINK. (You can guess the name of that 
>> linker!) Borland based their whole company's existence on fast 
>> compile-link times. Currently, ld is pig slow, it's a big bottleneck on 
>> the edit-compile-link-debug cycle on Linux.
> 
> That's not a good argument. ld is pig slow?  I'm sorry but I don't get
> that.  It works; it works as intended; and, strangely, I don't hear people
> complain about its apparent lack of speed. 
> 
> So what if a linker is blitzingly fast. If it's outdated and broken,
> there's not much to get excited about.  I'll choose the slow working one
> any day.

Ideally, perhaps a linker could provide both options: link fast and 
potentially bloat the exe or link carefully (and slowly) for a lean exe. 
  I'd use the fast link for debugging and the slow link for releases. 
Assuming, of course, that the linker were reliable enough that there was 
no risk of changing app behavior between the two.


Sean