Re: Dlpreopen on windows

[Ralf Wildenhues]

Hello Markus,

* Duft Markus wrote on Mon, Sep 25, 2006 at 05:18:21PM CEST:
> 
> Libtool generates a symbol table on the fly which it then compiles and
> links in, correct?
> That symbols table contains both .text and .data symbols. There is no
> problem with .text symbols so far ;o)
> As i saw the ....nmS file uses a one letter prefix to identify the type
> of symbol. My mdemo.nmS for exmaple has three types:
> 
>  T    .text i think, so all functions
>  B    .bss (??) i think, initialized data
>  C    .data (??) uninitialized data?

The types are derived from how `nm' on unices shows the ELF sections:
 "B" The symbol is in the uninitialized data section (known as BSS).
 "C" The  symbol  is common.  Common symbols are uninitialized data.  When 
linking,
     multiple common symbols may appear with the  same  name.   If  the  symbol 
 is
     defined anywhere, the common symbols are treated as undefined references.
 "D" The symbol is in the initialized data section.
 "T" The symbol is in the text (code) section.

We should probably change the mdemo test to not only test common symbols
(they are the least important), but to test initialized (to null and to
non-null) symbols.  Oh well, the stresstest in HEAD is useful for that.

> P.S.: the windows compiler does not define data symbols in object files
> if they are not referenced at least once in that object file. So the
> libtool mdemo/foo(1|2).c nothing variable is missing in the objects
> unless i initialize them with something (0 in my case...).

Hmm.  Is there a command line option to make it emit the common symbol?

Cheers,
Ralf