Lib change leads to larger executables

[jcc7]

== Quote from Frits van Bommel (fvbommel at REMwOVExCAPSs.nl)'s article
> 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) ?
> 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.
>
> Yes, that will "bloat" object files, but the current approach
> apparently bloats applications. Care to guess which are distributed
> most often? ;)

I think your idea could work. It makes sense to me, but I'd like to go one better:
Let's have DMD postpone creating TypeInfo until an .exe or .dll is being created
and only include them with the .obj for the "main" module (i.e. the module with
the main or DllMain function).

Surely, the compiler can figure out which TypeInfo's it needs at the point of
compiling an .exe or .dll. If not, even if we have to wait for linker to spit out
a list of missing TypeInfo's and then generate the TypeInfo (trial-and-error), I
think that would be a small price to pay for eliminating all of this bloat of
unneeded module that Kris has discovered.

There seems to be a lot more concern around here about .exe-size than there is
about the speed of compiling and linking. Let's fix what's broken -- even if we
have to give up a little compile/link speed

My idea seems too obvious to be the solution. Does anyone else think this would work?

By the way, Kris has a thorough description of the problem here:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=49257

jcc7