Lib change leads to larger executables

[Kristian Kilpi]

On Thu, 22 Feb 2007 22:08:46 +0200, Sean Kelly <sean at f4.ca> wrote:

> Kristian Kilpi wrote:
>> On Thu, 22 Feb 2007 18:32:18 +0200, Frits van Bommel  
>> <fvbommel at REMwOVExCAPSs.nl> wrote:
>>
>>> Sean Kelly wrote:
>>>> Ideally, perhaps a linker could provide both options: link fast and  
>>>> potentially bloat the exe or link carefully (and slowly) for a lean  
>>>> exe.  I'd use the fast link for debugging and the slow link for  
>>>> releases. Assuming, of course, that the linker were reliable enough  
>>>> that there was no risk of changing app behavior between the two.
>>>
>>> That might not be the case here: if a module's object file is pulled  
>>> in, that module's static constructors and destructors are called at  
>>> runtime, right? So if different modules are pulled in with those  
>>> options, different static constructors/destructors get called.
>>> (Same goes for unit tests, if enabled, by the way)
>>  Hmm, yes, but how that's different from the today's situation?  
>> Currently the linker chooses *arbitrary* object modules that happen to  
>> contain the needed typeinfo.
>
> Because as long as the list of dependencies remains unchanged, the same  
> arbitrary choices should be made.
>
>
> Sean

Well yes, except there is no guarantees of that, in the specs I mean.  
Another linker may (and likely will) produce a different result. And the  
same can happen when a library is rebuild. The order of object modules  
affect how the linker will choose modules to be linked in.