Lib change leads to larger executables

[Walter Bright]

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.

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

Most of the complexity in a linker stems from:

1) trying to make it fast
2) the over-complicated .obj file format

Conceptually, it is a very simple program.

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