Lib change leads to larger executables

[Frits van Bommel]

Justin C Calvarese wrote:
[snip]
> 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.

Oh, you want the compiler to parse the .obj files to generate some extra 
stuff before it tries to link?
So basically that would be Walters "Put all the TypeInfo instantiations 
into one special module and import it everywhere you need TypeInfo", but 
automated by the compiler when it gets to the point of linking an 
executable?
I'm not sure if that's workable either since I'm pretty sure it'll need 
to parse the source files to generate the TypeInfo, at the very least 
for user-defined types. At that point it may not even have access to 
those source files, especially when someone is using a closed-source 
library (via .di header files). This is also a problem with what I 
thought you meant, by the way.

[snip]
>>> 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. ;)

Thought so :).

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

I was kind of hoping the compiler wouldn't go looking for a new object 
file that includes a symbol it hasn't seen yet if it's present in the 
object file that needs it.
After seeing some more discussion on hash tables used in OMF linkers, 
I'm not sure if that's what would happen. It'd depend on how the linker 
is implemented, I guess.

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

Well, obviously it doesn't really matter if it works (and works well) :P.
Unfortunately, that doesn't currently seem to be the case...

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

Those bugs in OW might be fixed someday, or someone might re-implement 
OMF for the GNU toolchain (IIRC it was removed). Or someone else might 
want to implement a better linker for the Digital Mars compilers.
It's usually better to stick to published standards where they exist.

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

Thinking about it, I seem to recall "PE operations on non-PE file" to be 
a common error when I was trying to link ELF files on Windows 
(cross-compiled). MinGW-ld didn't seem to like ELF object files.
That was when linking to ELF binaries though, not to Windows executables.