Lib change leads to larger executables

kris foo at bar.com
Wed Feb 21 10:45:45 PST 2007


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?









More information about the Digitalmars-d mailing list