Re: [PATCH] apr_dso_open()

[Jonathan]

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