Lib change leads to larger executables
kris
foo at bar.com
Wed Feb 21 11:01:19 PST 2007
Pragma wrote:
> kris wrote:
>
>> kris wrote:
>>
>>> Walter Bright wrote:
>>>
>>>> kris wrote:
>>>>
>>>>> I've been messing with the response file handed to the librarian
>>>>> (via lib @foo); moving modules around here and there, reordering
>>>>> big chunks etc. Have yet to see a notable change in the resulting
>>>>> exe after relinking against each lib version.
>>>>
>>>>
>>>>
>>>>
>>>> Then look at the .map file to see what was linked in to the larger
>>>> file that wasn't in the smaller. Remove that module from the
>>>> library. Link again, and see what was unresolved. Rinse, repeat, and
>>>> you'll see what was pulling it all in.
>>>
>>>
>>>
>>> That's exactly what I'm doing, and I agree there seems to be
>>> something odd going on here. With ~200 modules, it's no slam-dunk to
>>> isolate it :)
>>
>>
>>
>> OK: narrowed it down to one obj file. The vast sea of data is coming
>> from the 'locale' package, which is stuffed to the gills with I18N
>> content.
>>
>> There's a half dozen modules in 'locale', none of which are used or
>> referenced by any other code in Tango, or by the example at hand. It
>> is an entirely isolated package (for obvious reason).
>>
>> Yes, there's the /potential/ for symbolic collision between 'locale'
>> and some other module/package. Let's consider that in a moment.
>>
>> In the meantime, I whittled the dependency down to one single module
>> listed right at the very end of the lib-response file (the very last
>> one to be added to the lib). This module is called Core.
>>
>> When Core is added to the lib, the linker emits "missing symbol"
>> errors since the rest of the locale package is missing. When Core is
>> removed, there are no link errors. This indicates some kind of
>> symbolic collision; one that is triggered by the very last module
>> added to the lib?
>>
>> So, sifting through the obj2asm output for Core, I see all the publics
>> are correctly prefixed by the package name. Thus, each symbol exposed
>> appears to be unique across the entire library. Except for one that
>> stands out. It is noted as an 'extern', yet is also listed amongst the
>> full set of publics in the obj2asm output; and it looks a bit
>> suspicious. Here's a small snippet from the ocean of public symbols in
>> Core:
>>
>> ====================
>> _D5tango4text6locale4Core18DaylightSavingTime5_ctorMFS5tango4text6locale4Core8DateTimeS5tango4text6locale4Core8DateTimeS5tango4text6locale4Core8TimeSpanZC5tango4text6locale4Core18DaylightSavingTime
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core18DaylightSavingTime5startMFZS5tango4text6locale4Core8DateTime
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core18DaylightSavingTime3endMFZS5tango4text6locale4Core8DateTime
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core18DaylightSavingTime6changeMFZS5tango4text6locale4Core8TimeSpan
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core8TimeZone18getDaylightChangesMFiZC5tango4text6locale4Core18DaylightSavingTime
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core8TimeZone18getDaylightChangesMFiZC5tango4text6locale4Core18DaylightSavingTime9getSundayMFiiiiiiiiZS5tango4text6locale4Core8DateTime
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core8TimeZone12getLocalTimeMFS5tango4text6locale4Core8DateTimeZS5tango4text6locale4Core8DateTime
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core8TimeZone16getUniversalTimeMFS5tango4text6locale4Core8DateTimeZS5tango4text6locale4Core8DateTime
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core8TimeZone12getUtcOffsetMFS5tango4text6locale4Core8DateTimeZS5tango4text6locale4Core8TimeSpan
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core8TimeZone20isDaylightSavingTimeMFS5tango4text6locale4Core8DateTimeZb
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core8TimeZone7currentFZC5tango4text6locale4Core8TimeZone
>> COMDAT flags=x0 attr=x0 align=x0
>> _D5tango4text6locale4Core8TimeZone5_ctorMFZC5tango4text6locale4Core8TimeZone
>> COMDAT flags=x0 attr=x0 align=x0
>> _D47TypeInfo_C5tango4text6locale4Core12NumberFormat6__initZ COMDAT
>> flags=x0 attr=x10 align=x0
>> _D49TypeInfo_C5tango4text6locale4Core14DateTimeFormat6__initZ
>> COMDAT flags=x0 attr=x10 align=x0
>> _D5tango4text6locale4Core14__T7arrayOfTiZ7arrayOfFAiXAi COMDAT
>> flags=x0 attr=x10 align=x0
>> _D5tango4text6locale4Core15__T7arrayOfTAaZ7arrayOfFAAaXAAa COMDAT
>> flags=x0 attr=x10 align=x0
>> _D12TypeInfo_AAa6__initZ COMDAT flags=x0 attr=x10 align=x0
>> __D5tango4text6locale4Core9__modctorFZv COMDAT flags=x0 attr=x0
>> align=x0
>> __D5tango4text6locale4Core9__moddtorFZv COMDAT flags=x0 attr=x0
>> align=x0
>> _D5tango4text6locale4Core8__assertFiZv COMDAT flags=x0 attr=x0
>> align=x0
>> _D5tango4text6locale4Core7__arrayZ COMDAT flags=x0 attr=x0 align=x0
>>
>> ====================
>>
>> You see the odd one out? That cursed _D12TypeInfo_AAa6__initZ again?
>
>
> Sorry if I'm stating the obvious, but it seems to me that the linker is
> finding this typeinfo COMDAT in Core first, rather than somewhere else,
> and is thereby forcing the inclusion of the rest of it's containing module.
>
> Does moving core.obj to the end of the .lib solve the problem?
>
Heya Eric
That's what it seems like and (as noted above) core.obj is already the
very last one added to the lib ;)
The only way to resolve at this point is to remove core.obj entirely.
More information about the Digitalmars-d
mailing list