On Nov 26, 2012, at 9:24 AM, Alexander Broekhuis <[email protected]> wrote:
> 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.. Would it make sense to ask this question on the APR dev list to make sure our assumptions are correct? Greetings, Marcel
