Lib change leads to larger executables

[Pragma]

kris 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.
> 
> In fact, it is so brittle and fragile that I now cannot reproduce what's 
> noted above. Back to square one where it does not matter if Core.obj is 
> listed first or last in the the lib "response file" -- it always gets 
> linked, resulting in a wildly bloated binary.
> 
> With Core.obj removed from the lib, the resultant binary is still 60KB 
> bigger than it should be, so the problem simply moves to a different bad 
> link-chain instead.

I made a pass at trying to reproduce this the last time out, with no success - that got swept under the rug as I quickly 
got caught up in a handful of other things.

If only there was some way to diagnose what the linker was doing, as it happened, we could easily map out what the 
suspect dependencies are.

-- 
- EricAnderton at yahoo