> At 02:48 AM 5/28/2003, William A. Rowe, Jr. wrote:
> >It seems like on Unix apr_dso_load() requires a suffix for the
> pathname but
> >on Windows it will provide one (.dll). WRT writing portable
> code...it looks
> >like Apache itself just uses .so on all platforms...or is there
> some other
> >mechanism? For example, a place where the appropriate platform-specific
> >suffix might be acquired?
>
> Definately a shortcoming. We should do both, perhaps ... provide
> the 'default'
> extention, e.g. .sl on hpux, while providing an APR_DSO_FILENAME_EXT
> value or something. Note that libs and modules are two different
> things on
> a few platforms, e.g. OS X, so we might need to take it a step
> further than that.
>
> Consider it a problem and feel free to profer a patch.
Not sure what I would proffer as a patch. Fixing apr_dso_load() to add the
appropriate suffix for a platform (where none is provided) will add some
processing time to each apr_dso_load() call, which would probably be
acceptable given the small number of calls per application. The fixed
pathname would need to be allocated from the provided pool, again probably
acceptable. But what about cases where the programmer intended no suffix?
On Windows this must be forced by appending a period and no suffix, which
might be a good solution. And the fix must be made in multiple places, I
believe, once per platform (with the exception of those that already do it
automagically).
Regardless, it is necessary to know what the appropriate extension should
be. So I suppose I would start by defining APR_DSO_FILENAME_EXT. I would
suppose that would go in apr_dso.h. I would start with something like the
following:
#if defined(WIN32) || defined(OS2)
#define APR_DSO_FILENAME_EXT "dll"
#elif defined(HPUX) || defined(HPUX10) || defined(HPUX11)
#define APR_DSO_FILENAME_EXT "sl"
#else
#define APR_DSO_FILENAME_EXT "so"
#endif
I'm uncertain of the proper operating system flags and suffixes, however.
And you mention OS X having separate suffixes for libraries and modules,
which further complicates matters (APR_DSO_LIB_FILENAME_EXT vs.
APR_DSO_MOD_FILENAME_EXT?).
I suppose I'm hemming and hawing because I'm not sure what the proper
solution _should_ be. If I'm on the right path, OK, I'll flesh something
out. But perhaps it isn't APR's responsibility to deal with this after all.
In the meantime, I would suggest the following change to apr_dso.h:
96,98d95
< * @note Using a path which does not have a suffix is non-portable.
< * On \e some operating systems a path will automatically be appended.
< * Portable code should always provide a suffix as part of the path.
which at least documents the issue and may in fact be a sufficient fix all
by itself, at least in the short run.
mma
