apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject HPUX Verbose - what about a new idea?
Date Mon, 09 Jun 2003 23:13:34 GMT
Before we entirely clobber the issue of HPUX's limited details about
shl errors, perhaps we might look at several key issues;

* Although we quiet the shl family of functions from emitting to stderr,
  this certainly isn't true of all libraries.  Anyone linking in 3rd party libs
  will undoubtedly discover that someplace, the author of some odd
  function took the easy way out and emitted to stderr.  The best we
  can do is limit these effects (many modperl users are familiar with
  the odd 'scalar leaked' emit in their httpd primary error log.)

* Sometimes, more is better.  That is, please help me diagnose my
  problem, and I don't care how many log files, etc I have to dig into.

* The odd library that simply performs it's own exec() will end up
  inheriting and using fd 0..2, there is no way around this issue, and
  the only safe thing is to retain the internal meaning of fd's 0-2, even
  at the cost of piping them to /dev/null.

I'd like to propose something that I hope the apr devheads might
accept; what if we either add to our apr_initialize (or invent another
construct) that asks APR to bypass all of its efforts to quiet the stray
emits that occur?

This might even help with Win32, where we would drop the DSO effort

On Win32, once that error mode is toggled, it is apparently impossible
to provide any meaningful information about why Win32 failed to perform
whatever DSO load it was requested to do.  No information is obtained
about what symbols or dependent libraries were not loadable.

As an -option-, this idea of invoking an apr_maintainer_mode(1) sort of
function could help many users debug problems that some given library
is very vebose at, but that the 'standard conventions' don't handle so well.


View raw message