Seema Alevoor wrote:
> Here is the patch which uses extended_FILE function
> (I'm unable to post the webrev as my build m/c is down).
> With this, duphi.patch is no longer needed.
>
> --- apr-1.3.3/misc/unix/start.c.orig Mon Sep 22 04:16:53 2008
> +++ apr-1.3.3/misc/unix/start.c Mon Sep 22 04:14:52 2008
> @@ -23,6 +23,10 @@
> #include "apr_arch_proc_mutex.h" /* for
> apr_proc_mutex_unix_setup_lock() */
> #include "apr_arch_internal_time.h"
>
> +#if defined(SOLARIS2) && !defined(_LP64)
> +#include <stdio_ext.h>
> +#endif
> +
> APR_DECLARE(apr_status_t) apr_app_initialize(int *argc,
> const char * const * *argv,
> const char * const * *env)
> @@ -46,6 +50,12 @@
> return APR_SUCCESS;
> }
>
> +#if defined(SOLARIS2) && !defined(_LP64)
> + if (enable_extended_FILE_stdio (-1, -1) < 0) {
> + return APR_FROM_OS_ERROR(errno);
this looks like a reasonable though slightly imperfect choice to me
in essence, we break some unknown but theoretically possible code that
relies on FILE._file that is used in the same process as APR apps like
httpd, and in return for that we allow normally written code to work
fine regardless of the number of open files, without extra
patches+syscalls to move file descriptors above 256 to leave room for
such unknown but theoretically possible code
such code
* isn't portable, so it doesn't fit the normal profile of code used with APR
* won't compile on OpenSolaris or future Solaris 11 anyway
* will encounter SIGABRT when it uses the FILE._file value in syscalls,
to allow it to be easily diagnosed
