Lib change leads to larger executables

[jcc7]

== Quote from Daniel Keep (daniel.keep.lists at gmail.com)'s article
> (I'm just going to interject here because WOW this thread is getting
> long; I can't even read the subject line anymore it's gone so far
> sideways...)
>
> There's one suggestion I haven't seen yet, so I'll make it:
>
> I assume from the discussion about segment-based linking that it's
> possible to pull out one particular section from an object file, and
> just link that into the executable.
>
> So, why not make a small modification to OPTLINK such that if a
> switch is thrown, and it encounters any missing symbol of the form
> /_D11TypeInfo_.*/, then it will link only the segment that symbol is
> in.  In other words, it does what it currently does in all cases
> except where there's a TypeInfo involved; in which case it links
> *just* the TypeInfo, not the whole object file.
>
> This doesn't break compatibility with OMF or any other tool; it's
> simply
> an optimisation for reducing executable bloat in D programs.  This
> way, we don't need a new object format, or a whole new linker.
>
> Or have I just got it all wrong? :P
> 	-- Daniel

I don't know enough about how linkers work to know if OPTLINK can just include a
TypeInfo segment like that, but it sounds like a good idea to me. I think it's
more feasible than my idea was (since Frits helped me see some serious challenges
with my idea).

And if it works, it should directly address Kris's problem.

jcc7