ld 'feature' failure to load some modules

[Leo de Wit]

In article <3787 at teklds.TEK.COM> steved at teklds.TEK.COM (Steve Dum) writes:
>
>When the loader is trying to resolve a undefined symbol, (nm says type 'U')
>if it finds a module which has the symbol declared as uninitialized data
>(nm says type 'C') in a library the loader extracts the size of the variable
>from that module, but it does not load in the module.  Does anyone know if
>this 'feature' is required by anything, or just due to historical reasons.
>It looks like a bug to me.

Depends on how you look at it. There is no need to load the entire module
from the loader's point of view. For a function this is different. It may
depend on locally defined functions (static that is).

>This is on a 4.3 system, but I don't think it is 4.3 specific.
>
>The reason I ask, is that this is exactly the wrong action for what I 
>want to do.  Namely, a c++ compiler can define data as uninitialized
>and also defines an initialiation routine which is resolved at load time
>by doing a partial load and then building a table of initialization
>routines to be called at program execution.  By only using the size, 
>and not loading the rest of the module the variable is defined in, 
>the code generated is incorrect.

You could say the c++ compiler is wrong in this respect, in that it
declares a variable to be uninitialized, and still handles it as
'variable to be automagically initialized', albeit by a runtime function.
Of course it is correct in doing so, the question is: is it correct to
depend on these expectations regarding the loader (i.e. inclusion of
complete modules)?
Using initialized variables (having a dummy value) wouldn't solve the
problem either; think of some compilers which store initialized strings
in ROM segments.
Maybe the c++ compiler should force a load of the initializing code by using it
in some way; anybody any suggestions?

                 Leo.