Lib change leads to larger executables
kris
foo at bar.com
Wed Mar 7 19:56:38 PST 2007
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.
More information about the Digitalmars-d
mailing list