Lib change leads to larger executables

[Walter Bright]

Derek Parnell wrote:
> If yes, will you be actively trying to find a satisfactory resolution in
> the near future?

I posted some suggestions to Kris.

> This has been pointed out a few times now; if any single item in an .OBJ
> file is referenced in the program, the whole .OBJ file is linked into the
> executable.

That's right. COMDATs make things slightly more complicated, as 
unreferenced COMDATs get discarded by the linker.

> This implies that in order to make small executable files, we need to
> ensure that .OBJ files are as atomic as possible and to minimize references
> to other modules. Yes, these are at conflict with each other so a
> compromise made be made somehow.
> 
> A better link editor would be able to only link in the portions of the .OBJ
> file that are needed, but until someone writes a replacement for OptLink,
> we are pretty well stuck with Walter's approach.

It's important to work with existing tools (like linkers and 
librarians), which (among other things) helps ensure that D programs can 
link with the output of other compilers (like gcc).

> Walter, I know that you are not going to change OptLink, so this next
> question is purely theoretical ... instead of finding the 'first' object
> file that resolves it, is there a better algorithm ... maybe the smallest
> object file that resolves it, or ... I don't know ... but it might be worth
> thinking about.

The 'smallest' doesn't do what you ask, either, because even the 
smallest obj file could contain a reference to something big.

>> Most of the complexity in a linker stems from:
>> 1) trying to make it fast
> How fast is fast enough?

It's never fast enough. I know a fellow who made his fortune just 
writing a faster linker than MS-LINK. (You can guess the name of that 
linker!) Borland based their whole company's existence on fast 
compile-link times. Currently, ld is pig slow, it's a big bottleneck on 
the edit-compile-link-debug cycle on Linux.


>> 2) the over-complicated .obj file format
> Can we improve the OBJ file format?

Only if we want to write a replacement for every tool out there that 
manipulates object files, and if we want to give up linking with the 
output of C compilers (or any other compilers).


>> Conceptually, it is a very simple program.
> And that might be a part of the problem.

Might be, but there also shouldn't be any confusion or mystery about 
what it's doing. Understanding how it works makes it possible to build a 
professional quality library. You can't really escape understanding it - 
and there's no reason to, it *is* a simple program.


>>> Yes, that will "bloat" object files, but the current approach apparently 
>>> bloats applications. Care to guess which are distributed most often? ;)
>> TypeInfo's are only going to grow, and this could create gigantic obj files.
> 
> So, have we got a problem or not?

Given limited resources, we have to deal with what we have.