celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha Zelzer <s.zel...@dkfz-heidelberg.de>
Subject Re: framework use some unix's function, not apr
Date Mon, 26 Nov 2012 08:35:08 GMT
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/%3C2661a376c77f8d7ecca23c8f9a2b6512@www.biol.unipr.it%3E

Mime
View raw message