[boost] Re: DLL library

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-23 06:19:24

Anthony Williams wrote:

>> I think this is reasonable use case. I wanted something similiar
>> recently. I have a library which calls user-provided 'userinit' function.
>> To allow the user to not provide the function, the library has its own
>> definition. So, when the library's version is called, it call 'dlsym' to
>> find the 'next' definition of 'userinit' and if it exists, calls it.
>>
>> But I'm afraid this semantic (find the next definition of symbol) is
>> Unix-specific. I'm not even sure if two symbols with the same names in
>> different DLLs are allowed on Windows.
> 
> On Windows the symbols from each DLL are entirely independent. However,
> you can specify at link time that certain symbols resolve to those from
> specific DLLs --- e.g. C++ standard library synbols resolve to the C++
> runtime DLL. If you try and import the same symbol from two DLLs at link
> time, then there is a name clash.

Do you mean that if two DLL define two identically named symbols (and that
symbol is present in both import libraries), then linking to both import
libraries is still OK. What mechanism is use to select one of the symbols?

> There is no concept of "next definition" --- you have to explicitly
> specify the DLL to search for the symbol.

Ok, noted.

>> But will this work for Windows? Can DLL have unresolved external
>> references? Are static initializers run when DLL is opened?
> 
> When a DLL is opened, Windows will implicitly call the exported
> initialization function. Whether or not your compiler uses this to run
> static initializers is up to the compiler vendor.

Understood. What happens in practice, say on VC?

> You cannot have "unresolved" external references under Windows. You must
> specify that a given symbol is found in a given DLL either at link time or
> at runtime, as described above.
> 
> If you want to have a "codegens" variable used by all the DLLs, then you
> probably ought to put it in a specific shared DLL, which is then
> referenced by all the others.
> 
> e.g.
> 
> codegens.dll --- contains definition of codegens from above

Ok, I think this is troublesome, but maybe possible to use.

- Volodya