Lib change leads to larger executables

[Derek Parnell]

Walter,
do we (the developer community) have a problem here? 

If yes, will you be actively trying to find a satisfactory resolution in
the near future?

On Wed, 21 Feb 2007 13:22:09 -0800, Walter Bright wrote:

> Frits van Bommel wrote:
>> kris wrote:
>>> Isn't there some way to isolate the typeinfo such that only a segment 
>>> is linked, rather than the entire "hosting" module (the one that just 
>>> happened to be found first in the lib) ?
> 
> No, the linker deals with .obj files as a unit.

This has been pointed out a few times now; if any single item in an .OBJ
file is referenced in the program, the whole .OBJ file is linked into the
executable.

This implies that in order to make small executable files, we need to
ensure that .OBJ files are as atomic as possible and to minimize references
to other modules. Yes, these are at conflict with each other so a
compromise made be made somehow.

A better link editor would be able to only link in the portions of the .OBJ
file that are needed, but until someone writes a replacement for OptLink,
we are pretty well stuck with Walter's approach.
 
>> The obvious solution would be to always generate typeinfo even if it can 
>> be determined imported modules will already supply it. The current 
>> approach seems to confuse the linker, causing it to link in unrelated 
>> objects that happen to supply the symbol even though the compiler 
>> "meant" for another object file to supply it.
> 
> I wish to be precise - there is no "seems" or "confuse" with linking. It 
> simply follows the algorithm I outlined previously - have an unresolved 
> symbol, find the first .obj module in the library which resolves it. It 
> does this in a loop until there are no further unreferenced symbols.

Walter, I know that you are not going to change OptLink, so this next
question is purely theoretical ... instead of finding the 'first' object
file that resolves it, is there a better algorithm ... maybe the smallest
object file that resolves it, or ... I don't know ... but it might be worth
thinking about.

 
> Most of the complexity in a linker stems from:
> 
> 1) trying to make it fast

How fast is fast enough?

> 2) the over-complicated .obj file format

Can we improve the OBJ file format?

> Conceptually, it is a very simple program.

And that might be a part of the problem.
 
>> Yes, that will "bloat" object files, but the current approach apparently 
>> bloats applications. Care to guess which are distributed most often? ;)
> 
> TypeInfo's are only going to grow, and this could create gigantic obj files.

So, have we got a problem or not?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
22/02/2007 10:01:57 AM