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 15:18:42 GMT
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

Mime
View raw message