apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan <...@wikifamilies.info>
Subject Re: [PATCH] apr_dso_open()
Date Mon, 09 Jan 2006 18:16:18 GMT
Joe Orton wrote:

>On Mon, Jan 09, 2006 at 08:35:07AM -0800, Jonathan wrote:
>  
>
>>Joe Orton wrote:
>>    
>>
>>>On Fri, Jan 06, 2006 at 12:05:36PM -0800, Jonathan wrote:
>>>      
>>>
>>>>LOCAL|NOW and GLOBAL|NOW only changes symbol depth. GLOBAL|NOW and 
>>>>LOCAL|LAZY allows symbol breadth and namespace breadth. I suggest 
>>>>another function, apr_dso_open_ex(), if we want more OS specific 
>>>>options. LOCAL|LAZY, however, is portable in likeness across other 
>>>>supported systems without dlopen().
>>>>        
>>>>
>>>Is that true for *all* the supported platforms, Win32, OS/2, Netware, 
>>>OS/390, etc etc?
>>>      
>>>
>>Here are some comments:
>>   * Win32 -defaults to private/local, has compile-time definitions for
>>     export/import (if supplied) otherwise run-time import is standard
>>     [I've tested]
>>   * OS/2 - defaults to private/local, compiler option to install
>>     automatic handler
>>    
>>
>...
>
>Thanks for doing the research.  Just to be clear, when you say 
>"compile-time" below, I presume you are talking about the compilation 
>time *of the DSO in question*, right?  So the answer to my question is 
>"no", you cannot change the dynamic linker behaviour at run-time in this 
>respect on all platforms?
>
>joe
>
>
>  
>
That is not what I intended by "compilation-time." If you look at some 
of the other implementations, you'll notice that they do not have code 
to import symbols at run-time. The compilations of the DSOs must have 
global symbols included. The function apr_dso_load() just would not work 
consistently without such table automatically loaded and binded. By the 
specifications of the different OSs, apr_dso_load() is not written to 
work consistently across the board. It works enough to get the job done. 
The limitations that you implied by "dynamic linker behavior at 
run-time" also exist the same for apr_dso_load(). A DSO without a global 
symbol table will break apr_dso_load() on some systems. Likewise, a DSO 
with a global symbol table would break apr_dso_open() on some systems.

Some systems are able to change the dynamic link behavior at run-time. 
Those that do not are not a show-stopper for apr_dso_open(). With 
apr_dso_load(), it presumes libraries are set-up to use a OS specific 
interface for global symbols, so it blindly opens a DSO. How is the APR 
team suppose to guarantee consistent behavior beyond apr_dso_load()'s 
blind functionality as stated here? APR wants to be portable.

What I suggest here is the first step -- remove the OS specific global 
system table. Use apr_dso_open() to open such DSOs with consistent 
behavior across the board. This step may need compile-time directives 
separate from run-time directives. I've shown by the list above that it 
is possible to have consistent behavior for the implementation of 
apr_dso_open() across the board.

Step two, which I didn't announce until this message, is to define an 
APR standard import implementation. For example, win32 does such with 
"COM", "OLE", and ".NET" DSO interfaces. This would mean that DSOs that 
want to be compatible with APR need to define an APR interface module. 
The interface module would do the import or export of symbol addresses, 
procedure calls, data, and so on. This is more portable, as a part of 
APR goals, because it uses less OS specific procedures. This allows us 
to do much more with DSOs. Like, we could implement a portable routine 
to query all exported procedures in a DSO.

For all other DSOs that are not compiled for the APR, we still have 
apr_dso_load(), or we provide apr_dso_open_ex().

Respectfully,
Jonathan


Mime
View raw message