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 Wed, 21 Sep 2005 15:50:33 GMT
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?

Mime
View raw message