Lib change leads to larger executables

[jcc7]

Frits van Bommel (fvbommel at REMwOVExCAPSs.nl) wrote:
> jcc7 wrote:
> > Frits van Bommel (fvbommel at REMwOVExCAPSs.nl) 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) ?
> >> 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:

(By the way, this topic is mostly over-my-head, so I'll probably have to quit
offering ideas pretty soon lest I embarrass myselft more than I already may have.)

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

Well, I don't want to prevent anyone from playing by their own rules, so my
proposed TypeInfo-postponing compiler could have a switch to add the TypeInfo as
it's compiling any arbitrary code into an .obj file. But in usual circumstances,
I'd think that the TypeInfo would only be needed when producing an .exe or .dll.

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

I don't see how static constructors and/or destructors interferes with the
compiler detecting which TypeInfo's would be necessary, but I don't think such a
problem would be insurmountable. Perhaps, it'd be a question of "Is it worth the
effort?".

But then again, I don't know much about what the compiler and linker do "under the
hood". It's mostly a black box for me. But from reading Walter and Kris discuss
the issues involved, I'm convinced there has to be a less haphazard way for DMD
and optlink to interact.


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

Isn't there still a question of whether anyone has found a "generic linker" for
OMF (other than OptLink) that can work with DMD anyway?


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

Yeah, that doesn't sound like fun.


> Though arguably the situation with DMD/Windows is already worse when
> it comes to that, since almost nobody else uses OMF anymore...

Right. We seem to be on our own when it comes to using OMF.

I think we're mostly trying to find a fix for the problem with the OMF files
generated by DMD right now. Apparently, GDC doesn't have these same problems (or
if GDC does have linker problems, Walter isn't the one responsible for fixing
them). So I think the problem is limited to using DMD's OMF files on Windows.
(Doesn't DMD on Linux use ELF? I think that's the case.)


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

You might be right, but I haven't given up hope yet.


jcc7