apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] apr_dso_load2() with flags support
Date Fri, 09 Sep 2005 16:10:52 GMT
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

Mime
View raw message