There are two functions that BenL and I recognized we need to support
a dynamic FIPS flavor of Apache/mod_ssl. We also need similar support
for the concept of nesting apriconv/* within the libaprutil.so's home
directory. In both cases, we *didn't* use apr_dso_load, so we are
unsure of the patch.
The OS's offer differing confidence in the quality of determining the
application binary's directory and a given auto-loaded dso's location,
however only apr is really in a position to give us this info, if it's
possible to obtain it at all.
I'd like comments/support/suggestions before I move forward with the
various implementations; I have three drafted but look forward to any
comments about the exact API's I've proposed.
Bill
Index: include/apr_general.h
===================================================================
--- include/apr_general.h (revision 224405)
+++ include/apr_general.h (working copy)
@@ -171,7 +171,8 @@
* Setup any APR internal data structures. This MUST be the first function
* called for any APR library.
* @remark See apr_app_initialize if this is an application, rather than
- * a library consumer of apr.
+ * a library consumer of apr. apr_app_fn() API's suffer if apr_initialize
+ * is used, instead of apr_app_initialize().
*/
APR_DECLARE(apr_status_t) apr_initialize(void);
@@ -186,12 +187,24 @@
* @remark See apr_initialize if this is a library consumer of apr.
* Otherwise, this call is identical to apr_initialize, and must be closed
* with a call to apr_terminate at the end of program execution.
+ * @warning This function MUST be called before any other libraries or
+ * code has an opportunity to manipulate the cwd (working directory),
+ * the argv[] or environ[] tables!
*/
APR_DECLARE(apr_status_t) apr_app_initialize(int *argc,
char const * const * *argv,
char const * const * *env);
/**
+ * Return the true pathname of this application (to the best of the
+ * platform's capability). Returns NULL if it truly cannot be worked
+ * out given this platform or errant results from apr_app_initialize().
+ * @remark apr_app_initialize must have been called, prior to any other
+ * change to the working directory, the argv[] or environ[] tables.
+ */
+APR_DECLARE(const char *) apr_app_pathname_get(void);
+
+/**
* Tear down any APR internal data structures which aren't torn down
* automatically.
* @remark An APR program must call this function at termination once it
Index: include/apr_dso.h
===================================================================
--- include/apr_dso.h (revision 224405)
+++ include/apr_dso.h (working copy)
@@ -76,6 +76,28 @@
const char *symname);
/**
+ * Resolve a dso pathname from a dso symbol (address) or partial name.
+ * @param filepath The returned filepath
+ * @param ressym A pointer to any symbol of the desired dso
+ * @param matchfile The short name of a dso, e.g. libfoo for
/usr/lib/libfoo.so.7
+ * @param pool A pool to to allocate the resulting filepath
+ * @remarks Some platforms will derive the loaded module directly
+ * from the ressym given, if it is an address in that loaded module's
+ * memory mapping. Others don't have this facility, but may track
+ * down filepaths from short names in the global symbol table.
+ * Note that given the example. libfoo, if libfoo.so.3 and libfoo.so.7
+ * are both loaded in memory, the result is not predictable.
+ * @bug Not every platform can return the full filepath; in general
+ * it is observed that most modern OS's return the full path for
+ * automatic dependencies, but may not return the full path for
+ * explicitly loaded DSOs which are loaded using a relative path.
+ */
+APR_DECLARE(apr_status_t) apr_dso_filepath_get(char **filepath,
+ void *ressym,
+ const char *matchfile,
+ apr_pool_t *pool);
+
+/**
* Report more information when a DSO function fails.
* @param dso The dso handle that has been opened
* @param buf Location to store the dso error
