Joe Orton wrote:
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.
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
* OS/2 - defaults to private/local, compiler option to install
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?
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().