Graham Leggett wrote:
Hi all,
The current dso helper code in apr-util masks the apr_dso_handle_t
structure from the caller, and in the process makes it impossible to
call apr_dso_error to find the human readable error message for why the
module failed to load.
The attached patch fixes this, making a change to the
include/private/apu_internal.h header file to expose the
apr_dso_handle_t structure.
The plan is to commit this to trunk only (1.4.x and later) - given that
the header is private, does this break the ABI rules?
The ABI rules generally allow internal changes.
However, -1 to this patch, as it is a private function and you haven't
actually demonstrated a use case. This implies you are relying on it
externally which defeats the 'private' declaration.
Likewise, the module handle is private.
apu_dso_load is transparent to the user. If misconfigured, the caller
(e.g. mod_ldap/mod_db[dm] caller) is clueless that this might have
happened. I suggest proposing a specific API for dealing with the
public aspects of apu_dso_load, and have both functions return some
"special case" error code for this purpose, which maps to the most
recent error result of apu_dso_load.
