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
