Lib change leads to larger executables
Pragma
ericanderton at yahoo.removeme.com
Thu Mar 8 08:06:36 PST 2007
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.
--
- EricAnderton at yahoo
More information about the Digitalmars-d
mailing list