Lib change leads to larger executables

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Thu Feb 22 07:26:33 PST 2007


jcc7 wrote:
> == 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).

Not all libraries may have a DllMain, IIRC it's completely optional.
On Windows it's required for D DLLs if you want to use the GC from 
within the DLL, or have static constructors/destructors in the DLL -- 
but otherwise you may get by without. I think if you write C-style D you 
may well get away without it.

> Surely, the compiler can figure out which TypeInfo's it needs at the point of
> compiling an .exe or .dll.

Not necessarily. Any modules that are linked in but not called by other 
modules (e.g. code only reachable from static constructors and/or static 
destructors) may not be seen when main/DllMain is compiled, if there 
even is one of these (see above point about DllMain being optional).

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

This would mean you can't "manually" link stuff together, using 
optlink/ld/whatever directly. I don't know how many people want to do 
this, but Walter has made it pretty clear he wants to be able to use a 
generic linker[1] (i.e. one that doesn't require specialized knowledge 
of D) and I agree with that.
Consider this: if every (or even more than one) language required a 
special way of linking, that would mean you couldn't link together code 
written in those languages without writing a linker (or perhaps wrapper) 
that supports both...
Though arguably the situation with DMD/Windows is already worse when it 
comes to that, since almost nobody else uses OMF anymore...

> 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

I agree.

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

For above-mentioned reasons, I don't think it will work for all 
(corner)cases.

> 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

I've seen it.



More information about the Digitalmars-d mailing list