You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2005/07/23 00:25:14 UTC
Proposal for 1.2 [nearing release]
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
Re: Proposal for 1.2 [nearing release]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:46 AM 7/25/2005, Joe Orton wrote:
>On Fri, Jul 22, 2005 at 05:25:14PM -0500, William Rowe wrote:
>...
>> /**
>> + * 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.
>
>If the results of this are not reliable this doesn't seem that useful.
>What platforms need the fuzzy matching against filenames?
The fact is; some applications will code this fuzzy-match (e.g. unwind
PATH or whatever else they have at their disposal) and such apps can't
benefit from a KNOWN binary location on those platforms which convey
this information.
Some examples include;
* modules such as FIPS, which must find themself and do a SHA-1
validation of the module file against a known-good signature.
* modules such as iconv where we would like to place the iconv
directory beside the libiconv.so, and have this iconv located
without the added hassle of envvars.
Bill
Re: Proposal for 1.2 [nearing release]
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Jul 22, 2005 at 05:25:14PM -0500, William Rowe wrote:
...
> /**
> + * 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.
If the results of this are not reliable this doesn't seem that useful.
What platforms need the fuzzy matching against filenames?
joe
Re: Borland/MinGW fixes
Posted by Curt Arnold <ca...@apache.org>.
On Jul 22, 2005, at 8:39 PM, William A. Rowe, Jr. wrote:
> Curt,
>
> I'm happy to review, but can't attack till I'm on vacation.
> Sympathies - yes it's taking too long to get foo reviewed lately.
>
> Hopefully 1.2.1 is postponed for a few days, and these are
> incorporated in the next release.
>
> Do they apply cleanly to 0.9? Do you care?
>
> Bill
Thanks. I haven't been concerned with 0.9, but will look at it and
confirm or submit a separate patch for that branch.
Re: Borland/MinGW fixes
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Curt,
I'm happy to review, but can't attack till I'm on vacation.
Sympathies - yes it's taking too long to get foo reviewed lately.
Hopefully 1.2.1 is postponed for a few days, and these are
incorporated in the next release.
Do they apply cleanly to 0.9? Do you care?
Bill
At 07:51 PM 7/22/2005, Curt Arnold wrote:
>It looks like yet another dot release without getting any of the
>compile problems on Borland and MinGW being knocked down. I hate
>trying to have these put in the last minute, but they have been
>waiting for review about 5 months now and nothing ever seems to
>move. Even if it is a partial integration of the most innocuous
>changes, getting any of them in would be better than nothing.
>
>http://issues.apache.org/bugzilla/show_bug.cgi?id=33490
Borland/MinGW fixes
Posted by Curt Arnold <ca...@apache.org>.
It looks like yet another dot release without getting any of the
compile problems on Borland and MinGW being knocked down. I hate
trying to have these put in the last minute, but they have been
waiting for review about 5 months now and nothing ever seems to
move. Even if it is a partial integration of the most innocuous
changes, getting any of them in would be better than nothing.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33490