httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: cvs commit: apache-2.0/src/lib/apr/misc/unix errorcodes.c
Date Mon, 29 May 2000 22:12:22 GMT
I agree - no hard coding of -ldl.

Oh, I'm back from my hols now, so I'm trying to catch up, but it'll take me
a while :))

david
----- Original Message -----
From: "Greg Stein" <gstein@lyra.org>
To: <new-httpd@apache.org>
Sent: Monday, May 29, 2000 10:56 PM
Subject: RE: cvs commit: apache-2.0/src/lib/apr/misc/unix errorcodes.c


> On Sun, 28 May 2000, William A. Rowe, Jr. wrote:
> >...
> > I respectfully suggest that this is a classic case where an #IFDEF
> > is entirely in order, and that ap_dso_error() should go away.
> > dlerror() was just fine.  I'd suggest a simple
> > #define HAVE_DLERROR
> > and include this only if we are building the stock unix dso support
> > into apr (as opposed to the linux build Jeff(?) was playing with).
>
> Again: DL is *not* the only way to load DSOs. All of that knowledge should
> be encoded into apr/dso/. APR should not be propagating (internally or
> externally) any notion of HAVE_DLERROR. That is way bogus.
>
> To answer Jeff's question: a hard-coded -ldl is almost certainly wrong.
>
> +1 on ap_dso_error() per Brian's ideas.
>
> APR_EDSOOPEN should return a hard-coded "DSO failed to open/load." string
> and be done with it. There should be no custom logic or #ifdef's in there.
> Note that the APR_EDSOOPEN is only returned when a platform does not
> already map the errors into the ap_status_t case (which Win32 does).
>
> Note that ap_dso_error() may need to defer to ap_strerror() for some
> platforms (such as Windows, where the ap_dso_handle_t has no extra info
> beyond that of the ap_status_t value).
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>


Mime
View raw message