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 to invoke SetErrorMode(SEM_FAILCRITICALERRORS); 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. Bill
