apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: [PATCH] apr_dso_load2() with flags support
Date Fri, 09 Sep 2005 16:45:10 GMT
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

Mime
View raw message