From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2004-07-23 07:31:43
Vladimir Prus <ghost_at_[hidden]> writes:
> 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?
No. You generally specify to directly import symbols from specific DLLs at
link time using their import libraries, but if two import libraries specify
the same symbols you can't do that.
With MSVC, you can generate an import library for one of the DLLs which omits
one or more symbols. This can be done using the /DEF option of the LIB
utility. Only the specified symbols are then imported from that DLL, and the
linker can resolve other calls against another DLL.
There may be other ways of doing this.
>>> 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?
VC runs the static initializers correctly for DLLs.
-- Anthony Williams Senior Software Engineer, Beran Instruments Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk