incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha Zelzer <>
Subject Re: framework use some unix's function, not apr
Date Mon, 26 Nov 2012 08:58:54 GMT
On 11/26/2012 09:35 AM, Sascha Zelzer wrote:
> 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]
> [2]

Funny, didn't see that the original posting in [2] was from Alexander ;-)

View raw message