Lib change leads to larger executables

[Pragma]

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?

-- 
- EricAnderton at yahoo