You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Joe Orton <jo...@redhat.com> on 2005/09/09 13:05:06 UTC
[PATCH] apr_dso_load2() with flags support
Any objections? This adds support for the usual RTLD_* flags to be
specified by the caller along with the glibc-specific and very useful
RTLD_DEEPBIND; any other implementation-specific flags can be added too
of course.
Index: include/apr_dso.h
===================================================================
--- include/apr_dso.h (revision 279575)
+++ include/apr_dso.h (working copy)
@@ -48,13 +48,53 @@
*/
typedef void * apr_dso_handle_sym_t;
+/**
+ * @defgroup apr_dso_open_flags DSO open flags
+ * @{
+ */
+#define APR_DSO_LAZY (0x0001) /**< Resolve symbols lazily;
+ undefined symbols will not
+ be noticed until used */
+#define APR_DSO_NOW (0x0002) /**< Resolve symbols at load time;
+ the DSO will fail to load if
+ symbols are undefined */
+#define APR_DSO_GLOBAL (0x0004) /**< Define symbols of loaded DSO
+ globally; they can be used by
+ subsequently loaded libraries */
+#define APR_DSO_LOCAL (0x0008) /**< Define symbols of loaded DSO
+ locally; they will not be visible
+ to subsequently loaded
+ libraries */
+#define APR_DSO_DEEPBIND (0x0010) /**< Resolve undefined symbols in
+ loaded libraries first in their
+ dependants then in global
+ scope. */
+
+#define APR_DSO_DEFAULT (0x0000) /**< Use default behaviour */
+
+/** @} */
+
/**
+ * Load a DSO. Any flags passed are taken as hints and may or
+ * may not be supported by the implementation. The flags
+ * APR_DSO_LAZY and APR_DSO_NOW are mutually exclusive.
+ * The flags APR_DSO_GLOBAL and APR_DSO_LAZY are mutually
+ * exclusive.
+ * @param handle Location to store new handle for the DSO.
+ * @param flags Advisory flags
+ * @param path Path to the DSO library
+ * @param pool Pool to use.
+ */
+APR_DECLARE(apr_status_t) apr_dso_load2(apr_dso_handle_t **handle,
+ const char *path,
+ apr_uint32_t flags,
+ apr_pool_t *pool);
+
+/**
* Load a DSO library.
* @param res_handle Location to store new handle for the DSO.
* @param path Path to the DSO library
* @param ctx Pool to use.
- * @bug We aught to provide an alternative to RTLD_GLOBAL, which
- * is the only supported method of loading DSOs today.
*/
APR_DECLARE(apr_status_t) apr_dso_load(apr_dso_handle_t **res_handle,
const char *path, apr_pool_t *ctx);
Index: dso/unix/dso.c
===================================================================
--- dso/unix/dso.c (revision 279575)
+++ dso/unix/dso.c (working copy)
@@ -77,9 +77,49 @@
return APR_SUCCESS;
}
-APR_DECLARE(apr_status_t) apr_dso_load(apr_dso_handle_t **res_handle,
- const char *path, apr_pool_t *pool)
+#ifdef DSO_USE_DLFCN
+/* Map APR_DSO_* flags to native RTLD_* flags. */
+static int dso_map_flags(apr_uint32_t flags)
{
+ int native = 0;
+
+ /* Default behaviour... */
+ if (flags == 0) {
+ flags = APR_DSO_GLOBAL | APR_DSO_NOW | APR_DSO_DEEPBIND;
+ }
+
+ if (flags & APR_DSO_GLOBAL) {
+ native |= RTLD_GLOBAL;
+ }
+#ifdef RTLD_LOCAL
+ else if (flags & APR_DSO_LOCAL) {
+ native |= RTLD_LOCAL;
+ }
+#endif
+
+ if (flags & APR_DSO_NOW) {
+ native |= RTLD_NOW;
+ }
+#ifdef RTLD_LAZY
+ else if (flags & APR_DSO_LAZY) {
+ native |= RTLD_LAZY;
+ }
+#endif
+
+#ifdef RTLD_DEEPBIND
+ if (flags & APR_DSO_DEEPBIND) {
+ native |= RTLD_DEEPBIND;
+ }
+
+ return native;
+#endif
+}
+#endif /* DSO_USE_DLFCN */
+
+APR_DECLARE(apr_status_t) apr_dso_load2(apr_dso_handle_t **res_handle,
+ const char *path, apr_uint32_t flags,
+ apr_pool_t *pool)
+{
#if defined(DSO_USE_SHL)
shl_t os_handle = shl_load(path, BIND_IMMEDIATE, 0L);
@@ -117,13 +157,12 @@
}
#elif defined(DSO_USE_DLFCN)
+ int os_flags = dso_map_flags(flags);
#if defined(OSF1) || defined(SEQUENT) || defined(SNI) ||\
(defined(__FreeBSD_version) && (__FreeBSD_version >= 220000)) ||\
defined(__DragonFly__)
- void *os_handle = dlopen((char *)path, RTLD_NOW | RTLD_GLOBAL);
-
+ void *os_handle = dlopen((char *)path, os_flags);
#else
- int flags = RTLD_NOW | RTLD_GLOBAL;
void *os_handle;
#ifdef _AIX
if (strchr(path + 1, '(') && path[strlen(path) - 1] == ')')
@@ -133,10 +172,10 @@
* dlopen() support for such a library requires that the
* RTLD_MEMBER flag be enabled.
*/
- flags |= RTLD_MEMBER;
+ os_flags |= RTLD_MEMBER;
}
#endif
- os_handle = dlopen(path, flags);
+ os_handle = dlopen(path, os_flags);
#endif
#endif /* DSO_USE_x */
@@ -163,7 +202,13 @@
return APR_SUCCESS;
}
-
+
+APR_DECLARE(apr_status_t) apr_dso_load(apr_dso_handle_t **handle,
+ const char *path, apr_pool_t *pool)
+{
+ return apr_dso_load2(handle, path, APR_DSO_DEFAULT, pool);
+}
+
APR_DECLARE(apr_status_t) apr_dso_unload(apr_dso_handle_t *handle)
{
return apr_pool_cleanup_run(handle->pool, handle, dso_cleanup);
Re: [PATCH] apr_dso_load2() with flags support
Posted by Jeff Trawick <tr...@gmail.com>.
On 9/9/05, Joe Orton <jo...@redhat.com> wrote:
> Any objections?
none here; some apps really want to use unfortunate BIND_VERBOSE
feature on HP-UX; this seems to be just the ticket
Re: [PATCH] apr_dso_load2() with flags support
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> So by "it must not expose special platform knowledge" you really mean
> "it must not allow callers to take advantage of features not available
> on all supported platforms"? I'd hoped to have seen the back of that
> tired old argument.
That is NOT what I said and you know that :)
> If APR is constrained to being no better than the lowest common
> denominator then APR is doomed. Please rescind the veto and let those
> of us who care about moving the code forward do so.
What I said was, define a behavior, not a platform-specific behavior,
and let's move on through this discussion to IMPLEMENT the damned
behaviors on all the platforms that support them.
I -said-, if you want dlopen(), use it. If you want APR, define just
what we need to do.
You want to use an undocumented, unsupported dlopen() flag, and tell
me that it's orthoginal to any sort of APR_DSO_PRIVATE/APR_DSO_LOCAL
behavior. I googled 'RTLD_DEEPBIND man' searching for any man page
documentation (it's sure not on my FC3's man page for dlopen) and
found nothing but a handful of posts by yourself on behalf of RH.
And rather than answer my question about "What does it do, and where
is it documented", you bemoan the fact that I won't turn apr_dso_load()
into dlopen().
My issue with naming APR_DSO_LOCAL is that it should define a behavior,
not a dlopen() flag, and from that perspective it will be confusing to
posix/dlopen users if APR_DSO_LOCAL triggered different flags on very
different platforms such as HPUX shl_*() api.
Do you really want to force the user to list out various shl_*() and
dlopen() and Win32 and OS/X dyld_*() flags just to accomplish something
that should be a single brain-dead simple-stupid flag?
Let's start by adopting your change for APR_DSO_PRIVATE in trunk, and
decide what that flag implies on the half-dozen platforms so that the
APR library provides portability?
Bill
Re: [PATCH] apr_dso_load2() with flags support
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Sep 21, 2005 at 11:25:33AM -0500, William Rowe wrote:
> Joe Orton wrote:
> >
> >If you want to propose an alternative interface please do it in full in
> >"diff -u" format, otherwise please give a technical justification for
> >your veto on what I proposed which makes more sense than "It must not
> >expose special platform knowledge".
>
> That is completely valid justification since this project's inception.
> If you aren't looking for portability, use dlopen(). If we are offering
> platform independence, we need to offer options (yes, I agree we need
> such options) that cleanly map to a certain behavior that can be
> supported on most platforms.
So by "it must not expose special platform knowledge" you really mean
"it must not allow callers to take advantage of features not available
on all supported platforms"? I'd hoped to have seen the back of that
tired old argument.
1) APR already has many such features, from apr_env_delete to
APR_POLLSET_THREADSAFE
2) the flags other than DEEPBIND can be supported on all POSIX platforms
and also the legacy HP-UX loader and the Darwin loader as already
discussed. that is "most platforms" enough for me anyway.
3) the flags can be exposed as hints/optional features without harming
application portability
If APR is constrained to being no better than the lowest common
denominator then APR is doomed. Please rescind the veto and let those
of us who care about moving the code forward do so.
joe
Re: [PATCH] apr_dso_load2() with flags support
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
> If you want to propose an alternative interface please do it in full in
> "diff -u" format, otherwise please give a technical justification for
> your veto on what I proposed which makes more sense than "It must not
> expose special platform knowledge".
That is completely valid justification since this project's inception.
If you aren't looking for portability, use dlopen(). If we are offering
platform independence, we need to offer options (yes, I agree we need
such options) that cleanly map to a certain behavior that can be
supported on most platforms.
Otherwise you are wasting cycles pushing and popping stacks to access
noop-wrapper code.
I offered a refined set of choices which deal with specific loading
details, as opposed to specific platform behaviors.
I cannot find any reference to RTLD_DEEPBIND, so if I was confused,
I appologize, but you are gonna have to back up a bit and explain
what construct your DEEPBIND request maps to. Since it's totally
undocumented, I'm very adverse to dealing with that flag at all.
Bill
Re: [PATCH] apr_dso_load2() with flags support
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Sep 21, 2005 at 10:50:33AM -0500, William Rowe wrote:
> Joe Orton wrote:
> >
> >>Can you define a few problems you want to solve, and we will map them
> >>to appropriate combinations of flags, and determine if they can be
> >>1) supported, 2) ignored, 3) not implemented across our platforms?
> >
> >I want to be able to load DSOs with RTLD_LOCAL to prevent population of
> >the global symbol table and I want to be able to loads DSOs with
> > RTLD_DEEPBIND to work around namespace collisions between libraries on
> > which said DSOs depend.
>
> Very cool! Ok, one down, we define APR_DSO_PRIVATE as one of the flags,
> which would mean local, and run the initializers (cpp constructors) to
> make the module usable. If RTLD_DEEPBIND is autoconf-detected, it can
> be added to the RTLD_LOCAL flag.
RTLD_DEEPBIND is orthogonal to RTLD_LOCAL.
> A second option, APR_DSO_STATIC, could have the same 'local' scope,
> however it would be used to load a module without initializers (on any
> platform which supports this) to simply query the data within the dso,
> e.g. if we wanted to look up the module_foo structure members in httpd.
> I'm not suggesting we do this now (unless someone asks), but we should
> distinguish between the two behaviors upfront. This flavor, on other
> platforms, could choose any sort of 'delayload' flag to further ensure
> we don't drag in subdependencies.
>
> Does this make sense?
Not really, too vague, I have no idea why the distinction between
APR_DSO_STATIC and APR_DSO_LOCAL is useful nor why you are bringing up
C++ initializers.
If you want to propose an alternative interface please do it in full in
"diff -u" format, otherwise please give a technical justification for
your veto on what I proposed which makes more sense than "It must not
expose special platform knowledge".
Regards,
joe
Re: [PATCH] apr_dso_load2() with flags support
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
>>Can you define a few problems you want to solve, and we will map them
>>to appropriate combinations of flags, and determine if they can be
>>1) supported, 2) ignored, 3) not implemented across our platforms?
>
> I want to be able to load DSOs with RTLD_LOCAL to prevent population of
> the global symbol table and I want to be able to loads DSOs with
> RTLD_DEEPBIND to work around namespace collisions between libraries on
> which said DSOs depend.
Very cool! Ok, one down, we define APR_DSO_PRIVATE as one of the flags,
which would mean local, and run the initializers (cpp constructors) to
make the module usable. If RTLD_DEEPBIND is autoconf-detected, it can
be added to the RTLD_LOCAL flag.
A second option, APR_DSO_STATIC, could have the same 'local' scope,
however it would be used to load a module without initializers (on any
platform which supports this) to simply query the data within the dso,
e.g. if we wanted to look up the module_foo structure members in httpd.
I'm not suggesting we do this now (unless someone asks), but we should
distinguish between the two behaviors upfront. This flavor, on other
platforms, could choose any sort of 'delayload' flag to further ensure
we don't drag in subdependencies.
Does this make sense?
Re: [PATCH] apr_dso_load2() with flags support
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Sep 21, 2005 at 09:46:33AM -0500, William Rowe wrote:
> Joe Orton wrote:
> >On Wed, Sep 21, 2005 at 09:03:54AM -0500, William Rowe wrote:
> >
> >>Ping since the thread tied here, and Joe's looking for an answer...
> >
> >Eh? Everything you say below is reasonable. But that doesn't help me
> >understand why you say the proposed API is "unportable" nor to resolve
> >your veto. What question do you need anybody else to answer?
> >
> >Again: can you propose an alternative apr_dso_open_ex() API so I can
> >understand your point?
>
> What I'm saying is that you *must not* have any special platform
> knowledge to use apr_dso_open_ex().
> Which means that picking from all of the flags and mapping the dlopen
> API as 'our new apr_dso_open' isn't the right solution.
What does "special platform knowledge" mean, and exactly what "special
platform knowledge" does the proposed API require?
> Can you define a few problems you want to solve, and we will map them
> to appropriate combinations of flags, and determine if they can be
> 1) supported, 2) ignored, 3) not implemented across our platforms?
I want to be able to load DSOs with RTLD_LOCAL to prevent population of
the global symbol table, and I want to be able to loads DSOs with
RTLD_DEEPBIND to work around namespace collisions between libraries on
which said DSOs depend.
joe
Re: [PATCH] apr_dso_load2() with flags support
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> On Wed, Sep 21, 2005 at 09:03:54AM -0500, William Rowe wrote:
>
>>Ping since the thread tied here, and Joe's looking for an answer...
>
> Eh? Everything you say below is reasonable. But that doesn't help me
> understand why you say the proposed API is "unportable" nor to resolve
> your veto. What question do you need anybody else to answer?
>
> Again: can you propose an alternative apr_dso_open_ex() API so I can
> understand your point?
What I'm saying is that you *must not* have any special platform
knowledge to use apr_dso_open_ex(). Which means that picking from all
of the flags and mapping the dlopen API as 'our new apr_dso_open' isn't
the right solution.
Can you define a few problems you want to solve, and we will map them
to appropriate combinations of flags, and determine if they can be
1) supported, 2) ignored, 3) not implemented across our platforms?
Bill
Re: [PATCH] apr_dso_load2() with flags support
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Sep 21, 2005 at 09:03:54AM -0500, William Rowe wrote:
> Ping since the thread tied here, and Joe's looking for an answer...
Eh? Everything you say below is reasonable. But that doesn't help me
understand why you say the proposed API is "unportable" nor to resolve
your veto. What question do you need anybody else to answer?
Again: can you propose an alternative apr_dso_open_ex() API so I can
understand your point?
>
> William A. Rowe, Jr. wrote:
> >Joe Orton wrote:
> >
> >>
> >>What's the default behaviour of the current API across all platforms?
> >>I have no idea, I expect it differs wildly from AIX to Windows and
> >>back. What exactly do you propose?
> >
> >
> >AIUI (and I don't necessarily agree with these choices, but we are stuck
> >;-)
> >
> >* Load Global. Every platform I'm aware of will map into the symbol
> > table. Now on Win32, OS2, and OS/X (using two-level namespace) these
> > symbols will be by-dso. E.g. these three examples actually have
> > multiple symbols of the same name, distinguished by the library's name.
> >
> > - disabling 'load global' is very effective for loading modules in
> > parallel. Name clashes in Linux cause dlopen to barf. Name clashes
> > on HP/UX produce 'arbitrary' results. Better to explicitly load
> > most libraries local, and then query the entry points, data or code,
> > as needed.
> >
> >* Bind Now, as we Run Constructors and Library Entry Points
> >
> > - disabling 'bind now' is actually a misnomer, what we are really
> > saying with bind deferred, IIUC, is that we plan to only grab
> > some static data or structures, and then dump the DSO without
> > it ever actually performing code operations.
> >
> >I think the bind now should be more abstract, to accomplish a specific
> >purpose. If they choose LAZY, are the dependent libraries and symbols
> >resolved when the library calls them? Consistant across platforms?
> >Would, say, LAZY on Linux allow the library to perform just-in-time sym
> >resolution, while LAZY on AIX might cause the library to crash when
> >trying to call an unresolved function?
> >
> >As long as the goal is to produce the fewest surprises for APR users
> >(developers) I'll be happy with the outcome :)
Re: [PATCH] apr_dso_load2() with flags support
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ping since the thread tied here, and Joe's looking for an answer...
William A. Rowe, Jr. wrote:
> Joe Orton wrote:
>
>>
>> What's the default behaviour of the current API across all platforms?
>> I have no idea, I expect it differs wildly from AIX to Windows and
>> back. What exactly do you propose?
>
>
> AIUI (and I don't necessarily agree with these choices, but we are stuck
> ;-)
>
> * Load Global. Every platform I'm aware of will map into the symbol
> table. Now on Win32, OS2, and OS/X (using two-level namespace) these
> symbols will be by-dso. E.g. these three examples actually have
> multiple symbols of the same name, distinguished by the library's name.
>
> - disabling 'load global' is very effective for loading modules in
> parallel. Name clashes in Linux cause dlopen to barf. Name clashes
> on HP/UX produce 'arbitrary' results. Better to explicitly load
> most libraries local, and then query the entry points, data or code,
> as needed.
>
> * Bind Now, as we Run Constructors and Library Entry Points
>
> - disabling 'bind now' is actually a misnomer, what we are really
> saying with bind deferred, IIUC, is that we plan to only grab
> some static data or structures, and then dump the DSO without
> it ever actually performing code operations.
>
> I think the bind now should be more abstract, to accomplish a specific
> purpose. If they choose LAZY, are the dependent libraries and symbols
> resolved when the library calls them? Consistant across platforms?
> Would, say, LAZY on Linux allow the library to perform just-in-time sym
> resolution, while LAZY on AIX might cause the library to crash when
> trying to call an unresolved function?
>
> As long as the goal is to produce the fewest surprises for APR users
> (developers) I'll be happy with the outcome :)
Re: [PATCH] apr_dso_load2() with flags support
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
> What's the default behaviour of the current API across all platforms? I
> have no idea, I expect it differs wildly from AIX to Windows and back.
> What exactly do you propose?
AIUI (and I don't necessarily agree with these choices, but we are stuck ;-)
* Load Global. Every platform I'm aware of will map into the symbol
table. Now on Win32, OS2, and OS/X (using two-level namespace) these
symbols will be by-dso. E.g. these three examples actually have
multiple symbols of the same name, distinguished by the library's name.
- disabling 'load global' is very effective for loading modules in
parallel. Name clashes in Linux cause dlopen to barf. Name clashes
on HP/UX produce 'arbitrary' results. Better to explicitly load
most libraries local, and then query the entry points, data or code,
as needed.
* Bind Now, as we Run Constructors and Library Entry Points
- disabling 'bind now' is actually a misnomer, what we are really
saying with bind deferred, IIUC, is that we plan to only grab
some static data or structures, and then dump the DSO without
it ever actually performing code operations.
I think the bind now should be more abstract, to accomplish a specific
purpose. If they choose LAZY, are the dependent libraries and symbols
resolved when the library calls them? Consistant across platforms?
Would, say, LAZY on Linux allow the library to perform just-in-time sym
resolution, while LAZY on AIX might cause the library to crash when
trying to call an unresolved function?
As long as the goal is to produce the fewest surprises for APR users
(developers) I'll be happy with the outcome :)
Bill
Re: [PATCH] apr_dso_load2() with flags support
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Sep 09, 2005 at 05:45:10PM +0100, Joe Orton wrote:
> On Fri, Sep 09, 2005 at 11:10:52AM -0500, William Rowe wrote:
> > Joe Orton wrote:
> > >Any objections? This adds support for the usual RTLD_* flags to be
> > >specified by the caller along with the glibc-specific and very useful
> > >RTLD_DEEPBIND; any other implementation-specific flags can be added too
> > >of course.
> >
> > Yup - the proposal you presented is totally nonportable, so -1 as
> > presented. Take a look at;
> >
> > http://www.hmug.org/man/3/dyld.php
>
> seems to have direct equivalents:
> APR_DSO_LOCAL -> NSLINKMODULE_OPTION_PRIVATE
> APR_DSO_NOW -> NSLINKMODULE_OPTION_BINDNOW
>
> > http://docs.hp.com/en/B2355-90695/shl_load.3X.html
>
> APR_DSO_NOW -> BIND_IMMEDIATE / APR_DSO_LAZY -> BIND_DEFERRED
> global/local hints ignored
>
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibraryex.asp
>
> all hints ignored AFAICT
>
> So what is "unportable" about this exactly? Platforms which don't
> implement the specified hints will ignore them as the apidoc describes.
ping regarding veto on "unportable" code.
Re: [PATCH] apr_dso_load2() with flags support
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Sep 09, 2005 at 11:10:52AM -0500, William Rowe wrote:
> Joe Orton wrote:
> >Any objections? This adds support for the usual RTLD_* flags to be
> >specified by the caller along with the glibc-specific and very useful
> >RTLD_DEEPBIND; any other implementation-specific flags can be added too
> >of course.
>
> Yup - the proposal you presented is totally nonportable, so -1 as
> presented. Take a look at;
>
> http://www.hmug.org/man/3/dyld.php
seems to have direct equivalents:
APR_DSO_LOCAL -> NSLINKMODULE_OPTION_PRIVATE
APR_DSO_NOW -> NSLINKMODULE_OPTION_BINDNOW
> http://docs.hp.com/en/B2355-90695/shl_load.3X.html
APR_DSO_NOW -> BIND_IMMEDIATE / APR_DSO_LAZY -> BIND_DEFERRED
global/local hints ignored
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibraryex.asp
all hints ignored AFAICT
So what is "unportable" about this exactly? Platforms which don't
implement the specified hints will ignore them as the apidoc describes.
> In terms of what -we- should do with an apr_dso_load_ex() or whatever
> it's named (aren't we using _ex designations?)...
Good point, I forgot APR follows that ugly windows convention.
> The new implementation can't define this in RTDL constructs; we need to
> decide default behavior; and then provide flags to override --- on those
> platforms which support the override. We also need to determine how an
> application determines if the platform supports the option, and how apr
> will react to an unrecognized/unsupported option.
What's the default behaviour of the current API across all platforms? I
have no idea, I expect it differs wildly from AIX to Windows and back.
What exactly do you propose?
joe
Re: [PATCH] apr_dso_load2() with flags support
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> Any objections? This adds support for the usual RTLD_* flags to be
> specified by the caller along with the glibc-specific and very useful
> RTLD_DEEPBIND; any other implementation-specific flags can be added too
> of course.
Yup - the proposal you presented is totally nonportable, so -1 as
presented. Take a look at;
http://www.hmug.org/man/3/dyld.php
http://docs.hp.com/en/B2355-90695/shl_load.3X.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibraryex.asp
(FYI, on HP/UX, shl API is used on PA32, while dl API is used on PA64...
I actually need to modify the ./configure schema to differentiate if we
are doing a PA32 or PA64 build.)
And note the BEOS, OS2 support no flags at all;
http://www.yellowtab.com/develop/dev_docs/doxygen_html/image_8h.html#a19
http://www.edm2.com/os2api/Dos/DosLoadModule.html
Really want to see something wild? Check out my favorite;
http://xaxxon.slackworks.com/phuku/sharedlib.html
In terms of what -we- should do with an apr_dso_load_ex() or whatever
it's named (aren't we using _ex designations?)...
The new implementation can't define this in RTDL constructs; we need to
decide default behavior; and then provide flags to override --- on those
platforms which support the override. We also need to determine how an
application determines if the platform supports the option, and how apr
will react to an unrecognized/unsupported option.
E.g. - by default dll's are loaded global, the override should try to
allow local, but what do we do when it's not supported by the platform?
There are also flags, especially on shl_load, which determine how
global constructors and destructors are invoked on load. Perhaps we
also need to be able to override these; our C++ users complained quite
frequently so we support them now, but perhaps there are applications
which need to disable that.
Anyways, +1 to the concept and effort, let's flesh this out first before
we modify an API that we become stuck with.
Bill