Lib change leads to larger executables

[Justin C Calvarese]

Frits van Bommel wrote:
> jcc7 wrote:
>> Frits van Bommel (fvbommel at REMwOVExCAPSs.nl) wrote:
>>> jcc7 wrote:
>>>> 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.
> 
> How static constructors could interfere:
> ---
> module selfcontained;
> 
> static this() {
>     // some code that requires TypeInfo not used in other modules
>     // (including Phobos), perhaps for a type defined in this module.
> }
> ---
> (Change 'static this' to 'static ~this' or 'unittest' for similar problems)
> 
> If this module isn't imported (directly or indirectly) from the file 
> defining main() the compiler can't possibly know what TypeInfo needs to 
> be generated for it when compiling main(), simply because it doesn't 
> parse that file when pointed at the file containing main().

Oh, I thought the .obj file included mentions of things that are needed, 
but not contained in a particular .obj. I thought that's why "Error 42: 
Symbol Undefined" will appear if I don't give the compiler enough source 
files.

If that's not right, that would be a serious flaw in my proposal.


> Yes, this could be "fixed" by having the module containing main() import 
> all such modules, but it shouldn't have to. We shouldn't need to work 
> around toolchain limitations, especially if there's a way to make it 
> Just Work(TM).
> 
>> Perhaps, it'd be a question of "Is it worth the
>> effort?".
> 
> It'll be worth the effort when one of _your_ projects fail to compile 
> because of it :P.

Well, of course, my plan is contingent upon my projects successfully 
compiling. ;)

[snip my older thoughts]

> Like I've mentioned earlier: I'm pretty sure this problem would go away 
> entirely if the compiler simply generated all TypeInfo used in the 
> module. If that generates larger intermediate object files I'm okay with 
> that. In fact, that was how I thought it worked until I started reading 
> about this problem...

If that'd solve the problem, that'd be an improvement from the status quo.

But I had the understanding that there is a problem with the linker 
picking the TypeInfo from an arbitrary .obj (such as a large module that 
isn't needed for a particular program)? I'm afraid the linker might 
continue to choose an inappropriate TypeInfo. Or do you plan for all of 
the TypeInfo's to be unique, thus probably still bloating the .exe (but 
in a different way)?


> [snip special linker discussion]
>>> 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.
> 
> Well, it seems OpenWatcom supports it. From what I've read here the 
> linker doesn't like DMD object files though. Walter claims it's buggy. I 
> don't know enough about OMF to say one way or the other.

Well, it doesn't really matter to me if DMD continues to use OMF if the 
format doesn't cause a bunch of bloat or other broken features. But I 
still wonder Walter needs to stay so close to the "official" format if 
DMC/DMD's OMF doesn't seems to be compatible with any other compiler.

[snip my older thoughts]

> Yes, DMD/Linux uses ELF. It just calls ld (through gcc) to link instead 
> of using optlink.
> 
> I'm not sure if ld (or the mingw port of it) can use ELF to create 
> Windows executables, but if it can that may be an option: just switch to 
> ELF entirely and trash optlink. (this paragraph wasn't entirely serious, 
> in case you hadn't noticed :P)

I suspect the option of ELF output would be welcomed by OMF's harshest 
critics. Not that I know anything about ELF.

-- 
jcc7