Lib change leads to larger executables

[Pragma]

Kristian Kilpi wrote:
> On Wed, 21 Feb 2007 11:00:44 +0200, Walter Bright 
> <newshound at digitalmars.com> wrote:
> 
>>> It does, but increases the exe size of the first example from 180kb 
>>> to 617kb!
>>  > 180kb is when compiled using build/rebuild/jake etc (no library) 
>> and the 617kb
>>  > is when using dmd+lib only. Same flags in both cases: none at all
>>
>> Let's say you have a template instance, TI. It is declared in two 
>> modules, M1 and M2:
>>
>> -----------M1------------
>> TI
>> A
>> -----------M2------------
>> TI
>> B
>> -------------------------
>>
>> M1 also declares A, and M2 also declares B. Now, the linker is looking 
>> to resolve TI, and the first one it finds is one in M1, and so links 
>> in M1. Later on, it needs to resolve B, and so links in M2. The 
>> redundant TI is discarded (because it's a COMDAT).
>>
>> However, suppose the program never references A, and A is a chunk of 
>> code that pulls in lots of other bloat. This could make the executable 
>> much larger than if, in resolving TI, it had picked M2 instead.
>>
>> You can control which module containing TI will be pulled in by the 
>> linker to resolve TI, by specifying that module first to lib.exe.
>>
>> You can also put TI in a third module that has neither A nor B in it. 
>> When compiling M1 and M2, import that third module, so TI won't be 
>> generated for M1 or M2.
> 
> Here's a quick thought. (It's probably too impractical/absurd. ;) ) 
> Could template instances to be put to their own, separate modules? Then 
> the linker will find a module containing the template instance only, and 
> no bloat will be pulled in with it. I don't know if this would require 
> the compiler to generate separate, extra .obj files for template 
> instances or something.

Nice idea, but I'd rather see the librarian to (optionally?) do this job instead.  It would avoid any complications for 
the existing toolchain by not introducing any behavior that is radically different from other platforms (i.e. "foo.d" 
==> "foo.obj" and "foo-t.obj").

Now if you're talking about breaking each-and-every COMDAT out into it's own .obj, then having the librarian do it is a 
must.  I can't imagine what my workspace would look like otherwise.

Either way, all this involves the rather messy business of turning each COMDAT fixup reference within an .obj file into 
an EXTERN.  I doubt that the DMD/DMC backend would make this job easy (I could be wrong!), so again, putting the job 
elsewhere (librarian) might be easier to maintain.

-- 
- EricAnderton at yahoo