Hi, As I understood it, your referenced link is about sharing module handles > between different processes. >
agreed. > > 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.. -- Met vriendelijke groet, Alexander Broekhuis
