Regular expression support is completely broken under HP-UX 11.0, whether in
core or in modules such as mod_rewrite.  Compiled with gcc 3.3 (32-bit) and with
most eveverything as DSOs (shared libraries).  Also compiled with OpenSSL 0.9.7c
 which are dynamic libraries themselves.

This appears to be a link-time conflict between the embedded PCRE library in
Apache and the libc system library in HP-UX.  HP's /usr/lib/libc.sl library
defines the code symbols regcomp, regexec, regerror, and regfree; all of which
are incompatible with pcre's posix api's (or at least pcre's headers).

I was able to determine that during the Apache compile, the embedded PCRE header
files were being used (which defined all the REG* enum identifiers, such as
REG_NOMATH=17).  But at runtime the call to regexec inside the APR wrappers (in
util.c) would routinely get back result codes of 20.  Under HP-UX, REG_NOMATCH
is defined to be 20.  Interesting no core was ever produced, but no regex's
would match either.

I was also able to determine that during the libtool linking of .libs/httpd that
the pcreposix.o object file would never be inserted into the executable (despite
the pcre library being presented to libtool's link command).

By carefully reordering the low-level link command executed by libtool, I was
able to force the pcreposix.o object file into httpd.  I basically moved the
pcre library immediately after libmain instead of after all the OpenSSL dynamic
library link flags.  This allowed the core regex's to work (such as in
DirectoryMatch), but those in modules such as mod_rewrite would still fail.

I eventually got everything to work by simply renaming the four functions in the
Apache codebase so they no longer conflicted with HP's:

   regcomp()  ->  posix_regcomp()
   regexec()  ->  posix_regexec()
   regerror() ->  posix_regerror()
   regfree()  ->  posix_regfree()

Those appear in these source files:

  server/util.c
  srclib/apr/test/internal/testregex.c
  srclib/pcre/pcreposix.c, .h
  srclib/pcre/pcretest.c
  include/pcreposix.h

With no changes other than renaming those four function identifiers, regular
expressions are now fully working both in core and in modules.