You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jonathan <bj...@wikifamilies.info> on 2006/01/06 17:04:53 UTC
[PATCH] apr_dso_open()
Comments?
This adds apr_dso_open(). Its intention is to only open a dynamic shared
library and to do so without any further process to automatically bind
global symbols, unlike apr_dso_load().
Jonathan
Re: [PATCH] apr_dso_open()
Posted by Jonathan <bj...@wikifamilies.info>.
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
Re: [PATCH] apr_dso_open()
Posted by Joe Orton <jo...@redhat.com>.
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
Re: [PATCH] apr_dso_open()
Posted by Jonathan <bj...@wikifamilies.info>.
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?
>
>joe
>
>
>
>
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
* OS/390 - defaults to private/local, various compile-time
environments (some may default to automatically add routines to
add run-time export/import automation)
* BeOS - defaults to private/local, assumed compile-time options
available
* Netware - has dlopen()
* AIX (older)- simulated by lower-level routine/accesss, able to
modify to make symbols not global
* Darwin 10.1 - has NSAddImage() for private/local [I've tested]
* Darwin 10.2 - has NSLINKMODULE_OPTION_PRIVATE on NSLinkModule()
* Darwin 10.3 - has dlopen()
* HP - has BIND_DEFFERED and shl_findsym()
* linux/unix with dlopen() - yes [I've tested]
Please, let me know if I have missed any.
Jonathan
Re: [PATCH] apr_dso_open()
Posted by Joe Orton <jo...@redhat.com>.
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?
joe
Re: [PATCH] apr_dso_open()
Posted by Jonathan <bj...@wikifamilies.info>.
Joe Orton wrote:
>On Fri, Jan 06, 2006 at 08:04:53AM -0800, Jonathan wrote:
>
>
>>Comments?
>>
>>This adds apr_dso_open(). Its intention is to only open a dynamic shared
>>library and to do so without any further process to automatically bind
>>global symbols, unlike apr_dso_load().
>>
>>
>
>Splitting the differrent implementations into separate files should be
>done separately to adding any new interfaces; if you wanted to submit a
>patch for that it's probably be a good idea.
>
>
That can be done.
>For the new interface: offering GLOBAL|NOW and LAZY|LOCAL as the only
>two options is just odd; the most common uses I'd see would be
>GLOBAL|NOW and LOCAL|NOW, LAZY is useful only in rare cases.
>
>
RTLD_NOW is useful for DLLs that expect to export symbols and to debug
code. It does not work well for DLLs that are set-up to import symbols
and that take advantage of private/local DLL namespace, especially when
mixed with code that expects exported symbols. RTLD_LAZY is not
uncommon. It is, perhaps, less used because it requires a bit more work
to code properly. Some systems do the equivalent of RTLD_LAZY, by
default, and require a explicit flag or such to bind everything
immediately. With RTLD_LAZY, it is possible to not export any symbols
and not cause any bind and still access the code in a library through
dlsym(), yet, with RTLD_NOW, it can be done automatically or automated
with compiler options. That automatic bind is not always desirable.
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().
>I think any new function should just use flags to allow the user to
>choose any of the four combinations where possible. (I don't understand
>the vetoes on previous patches which did that, so I can't offer any
>advice on how to do this without still incurring a veto; try it and see
>I guess)
>
>Regards,
>
>joe
>
>
>
>
Not all systems have only four options and the same likeness in options.
We can, however, limit it to two functions, for now, instead of just the
only one that we have.
Best,
Jonathan
Re: [PATCH] apr_dso_open()
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Jan 06, 2006 at 08:04:53AM -0800, Jonathan wrote:
> Comments?
>
> This adds apr_dso_open(). Its intention is to only open a dynamic shared
> library and to do so without any further process to automatically bind
> global symbols, unlike apr_dso_load().
Splitting the differrent implementations into separate files should be
done separately to adding any new interfaces; if you wanted to submit a
patch for that it's probably be a good idea.
For the new interface: offering GLOBAL|NOW and LAZY|LOCAL as the only
two options is just odd; the most common uses I'd see would be
GLOBAL|NOW and LOCAL|NOW, LAZY is useful only in rare cases.
I think any new function should just use flags to allow the user to
choose any of the four combinations where possible. (I don't understand
the vetoes on previous patches which did that, so I can't offer any
advice on how to do this without still incurring a veto; try it and see
I guess)
Regards,
joe
Re: [PATCH] apr_dso_open()
Posted by Jonathan <bj...@wikifamilies.info>.
Garrett Rooney wrote:
>On 1/6/06, Jonathan <bj...@wikifamilies.info> wrote:
>
>
>>Comments?
>>
>>This adds apr_dso_open(). Its intention is to only open a dynamic shared
>>library and to do so without any further process to automatically bind
>>global symbols, unlike apr_dso_load().
>>
>>
>
>This seems reasonably useful to me, I'm just curious if it can be
>portably implemented. It looks like you've got code in there for
>dlopen and whatever Mac OS X uses, what about the other systems we
>support?
>
>-garrett
>
>
>
>
I've just read all the specifications for all the supported systems, and
it appears it can be done consistently. That does not mean it can be
guaranteed because some systems let the DLL override options on how
global symbols are loaded, but a requirement to compile a DLL in a
certain way helps solve such inconsistency.
Re: [PATCH] apr_dso_open()
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/6/06, Jonathan <bj...@wikifamilies.info> wrote:
> Comments?
>
> This adds apr_dso_open(). Its intention is to only open a dynamic shared
> library and to do so without any further process to automatically bind
> global symbols, unlike apr_dso_load().
This seems reasonably useful to me, I'm just curious if it can be
portably implemented. It looks like you've got code in there for
dlopen and whatever Mac OS X uses, what about the other systems we
support?
-garrett