You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2005/05/03 01:24:01 UTC

Revert svn commit 64143 - HP/UX shl_load

Modified Wed Dec 11 19:37:08 2002 UTC (2 years, 4 months ago) by jorton 
File length: 9449 byte(s) 

Don't pass BIND_VERBOSE to shl_load(), else it dumps errors to stderr
by default.


http://svn.apache.org/viewcvs.cgi/apr/apr/trunk/dso/unix/dso.c?rev=64143&r1=63863&r2=64143&diff_format=h
I'd like to propose reverting this commit on all apr branches;

The dlerror() function on HP/UX does -not- provide any details
of WHAT symbol or dependent module failed to load, on shl_load().
Although error details to stderr are certainly not elegant, I'm
not seeing any alternative to reintroducing BIND_VERBOSE.

Because most cases are fatal anyways, the extra stderr noise seems
a minor penalty for useful diagnostics.

Thoughts?

Bill  


Re: Revert svn commit 64143 - HP/UX shl_load

Posted by Jeff Trawick <tr...@gmail.com>.
On 5/2/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:

> Don't pass BIND_VERBOSE to shl_load(), else it dumps errors to stderr
> by default.

> The dlerror() function on HP/UX does -not- provide any details
> of WHAT symbol or dependent module failed to load, on shl_load().
> Although error details to stderr are certainly not elegant, I'm
> not seeing any alternative to reintroducing BIND_VERBOSE.

sucks

> Because most cases are fatal anyways, the extra stderr noise seems
> a minor penalty for useful diagnostics.

apr_dso_load_ext() with new options parameter which can be used to say
it is okay to dump diagnostics info to stderr?  Apache might turn this
on; some other app might not.

Some fancy logic (not considered safe/simple/practical by me, but YMMV ;) )

try it without BIND_VERBOSE; if it fails:
move current fd 2 to some other fd
close fd 2; create temporary file as fd 2
try the load again with BIND_VERBOSE
capture info in fd 2 to memory for reporting on apr_dso_error()
close fd 2
restore old fd2 usage

Re: Revert svn commit 64143 - HP/UX shl_load

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, May 4, 2005 4:30 PM +0100 Joe Orton <jo...@redhat.com> 
wrote:

> It's up to the caller whether it's fatal.  It's a perfectly valid use of
> the interface to ignore apr_dso_open() errors; image an application
> which optimistically opens a set of named extension modules, some of
> which might not be present.  If a particular extension can't be loaded
> the app could just ignore it and carry on.  It did *not* ask for stuff
> to be printed to stderr, so APR should not do that either.

Yup, that's the problem that I remember.  FWIW, Subversion has this 
optimistic behavior.  BIND_VERBOSE is bad.  -- justin

Re: Revert svn commit 64143 - HP/UX shl_load

Posted by Joe Orton <jo...@redhat.com>.
On Mon, May 02, 2005 at 06:24:01PM -0500, William Rowe wrote:
> Modified Wed Dec 11 19:37:08 2002 UTC (2 years, 4 months ago) by jorton 
> File length: 9449 byte(s) 
> 
> Don't pass BIND_VERBOSE to shl_load(), else it dumps errors to stderr
> by default.
>
> http://svn.apache.org/viewcvs.cgi/apr/apr/trunk/dso/unix/dso.c?rev=64143&r1=63863&r2=64143&diff_format=h
> I'd like to propose reverting this commit on all apr branches;
> 
> The dlerror() function on HP/UX does -not- provide any details
> of WHAT symbol or dependent module failed to load, on shl_load().
> Although error details to stderr are certainly not elegant, I'm
> not seeing any alternative to reintroducing BIND_VERBOSE.
>
> Because most cases are fatal anyways, the extra stderr noise seems
> a minor penalty for useful diagnostics.

It's up to the caller whether it's fatal.  It's a perfectly valid use of
the interface to ignore apr_dso_open() errors; image an application
which optimistically opens a set of named extension modules, some of
which might not be present.  If a particular extension can't be loaded
the app could just ignore it and carry on.  It did *not* ask for stuff
to be printed to stderr, so APR should not do that either.

Regards,

joe