Joe Orton wrote:
So by "it must not expose special platform knowledge" you really mean "it must not allow callers to take advantage of features not available on all supported platforms"? I'd hoped to have seen the back of that tired old argument.
That is NOT what I said and you know that :)
If APR is constrained to being no better than the lowest common denominator then APR is doomed. Please rescind the veto and let those of us who care about moving the code forward do so.
What I said was, define a behavior, not a platform-specific behavior, and let's move on through this discussion to IMPLEMENT the damned behaviors on all the platforms that support them. I -said-, if you want dlopen(), use it. If you want APR, define just what we need to do. You want to use an undocumented, unsupported dlopen() flag, and tell me that it's orthoginal to any sort of APR_DSO_PRIVATE/APR_DSO_LOCAL behavior. I googled 'RTLD_DEEPBIND man' searching for any man page documentation (it's sure not on my FC3's man page for dlopen) and found nothing but a handful of posts by yourself on behalf of RH. And rather than answer my question about "What does it do, and where is it documented", you bemoan the fact that I won't turn apr_dso_load() into dlopen(). My issue with naming APR_DSO_LOCAL is that it should define a behavior, not a dlopen() flag, and from that perspective it will be confusing to posix/dlopen users if APR_DSO_LOCAL triggered different flags on very different platforms such as HPUX shl_*() api. Do you really want to force the user to list out various shl_*() and dlopen() and Win32 and OS/X dyld_*() flags just to accomplish something that should be a single brain-dead simple-stupid flag? Let's start by adopting your change for APR_DSO_PRIVATE in trunk, and decide what that flag implies on the half-dozen platforms so that the APR library provides portability? Bill
