Lib change leads to larger executables

[Don Clugston]

Pragma wrote:
> Sean Kelly wrote:
>> kris wrote:
>>> Walter Bright wrote:
>>>> kris wrote:
>>>>
>>>>> Walter Bright wrote:
>>>>>
>>>>>> Sure, but in this particular case, it seems that "core" is being 
>>>>>> imported without referencing code in it. The only reason the 
>>>>>> compiler doesn't generate the char[][] TypeInfo is because an 
>>>>>> import defines it. The compiler does work on the assumption that 
>>>>>> if a module is imported, then it will also be linked in.
>>>>>
>>>>> This core module, and the entire locale package it resides in, is 
>>>>> /not/ imported by anything. I spelled that out clearly before. 
>>>>> You're making an assumption it is, somehow ... well, it is not. You 
>>>>> can deduce that from the fact that the link succeeds perfectly well 
>>>>> without that package existing in the library.
>>>
>>> After taking a much needed break from this, I'm having another bash 
>>> at it. The locale package highlighted in the last bout has been 
>>> through a number of changes, and thus the behaviour will now be 
>>> somewhat different than before.
>>>
>>> For a refresher on this issue, here's an overview: 
>>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=49257 
>>>
>>>
>>> The upshot is that reordering the content as presented to the 
>>> librarian now has an effect on the resultant binary size. This tells 
>>> me two things:
>>>
>>> 1) there were more than just the one compiler-generated unresolved 
>>> symbol in the first case, though I did not spot it after many 
>>> painstaking hours of frustrating effort. In fact, there may well have 
>>> been a number of vaguely intertwined dependencies spread throughout 
>>> the library, due entirely to these compiler-generated symbols.
>>>
>>> 2) there is no feasible manner in which a developer can control how 
>>> lib contents are linked while the compiler continues to generate 
>>> duplicate symbols under the covers. The fact that it does this on a 
>>> regular basis simply serves to highlight a critical problem.
>>>
>>>
>>>  > Then the typeinfo for char[][] is being generated by another 
>>> module. I
>>>  > suggest it would be helpful to find that module. Grep is a handy tool
>>>  > for finding it.
>>>
>>> What would be the point? These symbols are compiler generated, and 
>>> exist in a variety of places because of that fact alone. Lest we 
>>> forget, we're not even talking about just one symbolic name ~ the 
>>> compiler generates duplicate symbols for any typeinfo that does not 
>>> match the pre-packaged list (such as char[][]). The end result is a 
>>> potential rats-nest of duplicate symbols, creating a maze of 
>>> intricate and fragile dependencies across the lib itself.
>>>
>>> To put things into perspective, I have absolutely no way of knowing 
>>> what the real dependencies within this library actually are. As such, 
>>> I'd have to describe the situation as being "out of control". This is 
>>> wholly due to the duplicate compiler-generated symbols.
>>
>> It's a long-term proposition, but what about delaying the generation 
>> of TypeInfo until link-time?  The MS linker already optionally 
>> performs code generation to allow for more optimized executables, so I 
>> assume such a thing is definitely possible.  It would obviously 
>> require a new linker, but I don't see any other way to address these 
>> "silent dependency" issues, etc.  If I had the time I'd try it out, 
>> but as things stand there's no way that could happen before September.
> 
> I was going to say: new linker == our problem.  I'm in the same boat on 
> the no time thing, but maybe we can get a group effort going later on.  
> If for no other reason, we could investigate what a native 64-bit 
> toolchain for D on Windows might look like.

I've been wondering how far your work with DDL goes towards writing a 
linker? Certainly the work you've done with making sense of the OMF and 
ELF specs, and parsing the obj files, seems to be a huge chunk of the 
task. A lot of code would be common to both tasks, surely?