Lib change leads to larger executables

kris foo at bar.com
Wed Mar 7 17:35:04 PST 2007


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.



More information about the Digitalmars-d mailing list