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 Wed, 21 Sep 2005 16:14:26 GMT
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

Mime
View raw message