On 11/26/2012 09:24 AM, Alexander Broekhuis wrote:
I am not a Windows DLL expert but I think the following is true (maybe
there are some tricks on the Windows platform, but they would definitely be
non-standard):
Vaguely speaking, the Windows linker resolves symbols at link-time,
contrary to the default behaviour of the ELF linker, resolving symbols
lazily at runtime. Therefore, the concept of a symbol search path makes not
much sense on Windows (except for the search path defined by the link-time
dependencies). Consequently, dynamically loaded libraries on Windows do not
affect symbol resolution of subsequently loaded libraries so their symbols
are never "global". RTLD_GLOBAL on POSIX systems adds the symbols of the
loaded library to the global search path, hence they can be used by the
dynamic linker to resolve symbols of subsequently loaded libraries. There
is no such "global symbol search path" on Windows (AFAIK).
If this is the case then Celix won't have a problem on Win32 systems...
Even more, the behavior of APR is inconsistent.. on Linux based systems
GLOBAL is the default, while Windows doesn't have a GLOBAL equivalent. I
would have thought the default APR behavior to try to be the same over
multiple platforms..
Seems so... using RTLD_GLOBAL is generally regarded as being "harmful"
and its usage should be avoided or at least minimized, see [1] and APR
related here [2]. For Celix, it should work out-of-the-box on Windows,
provided that all needed __declspec(export) attributes are in place.
[1] http://www.akkadia.org/drepper/dsohowto.pdf
[2]
http://mail-archives.apache.org/mod_mbox/apr-dev/201105.mbox/%[email protected]%3E
