You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2000/05/26 23:03:33 UTC
Re: building on Unix this a.m.
> Fetching that string should be an APR-internal function from the dso/
> area. Only the DSO modules are going to know how to fetch the string.
>
> There shouldn't be a HAVE_DLERROR, as all knowledge of that stuff "should
> be" isolated to the dso/ directory.
That's not the way anything in APR currently works. I haven't really
figured out the best way to do this, but creating a new solution is
sub-optimal IMHO.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: building on Unix this a.m.
Posted by rb...@covalent.net.
> What?! It already HAS a DSO feature. Go look at src/lib/apr/dso/win32/
Sorry. I went from memory instead of looking at code, you can ignore my
whole message. I'll probably just implement what you suggest, because it
is the best solution.
Sorry to cause a rucus. It's not a good day. Expect a commit in a few
minutes.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: building on Unix this a.m.
Posted by Greg Stein <gs...@lyra.org>.
On Fri, 26 May 2000 rbb@covalent.net wrote:
> The fact is, there are only two options right now for where to get the dso
> error string from, errno and dlerror.
Incorrect. The "dl" library is only one mechanism for loading DSOs. Python
has TEN mechanisms: AIX, BeOS, DL, HP/UX, Mac, NeXT, OS/2, SHLIB, and
Win32. Each has their own loading and error reporting mechanisms.
> errno is already taken care of, and
> dlerror make sense where it is if it is the only other option.
>
> Now, if/when Windows implements a dso feature,
What?! It already HAS a DSO feature. Go look at src/lib/apr/dso/win32/
> we can/should re-visit
> this. The real solution IMNSHO, is to use a feature macro for APR
> here. Basically allow DSO to be turned on/off from the configure
> line. This way, when there is no DSO handling in Apache, this error
> message changes. If there is DSO handling, we grab it from dlerror the
> same way we are doing now.
I don't think this is the right answer. I'm not sure how it can work,
given the disparate ways to load a DSO.
> The other fact is that this code was broken on Windows because that
> feature macro doesn't exist, and this error isn't used on Windows. The
Has nothing to do with feature macros. Assuming DL in the first place is
wrong.
> build on Unix is broken because we aren't using the right libraries, which
> goes back to a configuration issue.
Yup. But DL is not the "right library" in many cases.
Again: I believe the proper way to do this, is to ask the dso/ directory
for how to resolve errors from DSO loading.
Cheers,
-g
>
> Ryan
>
> > Fine, but using dlerror() in the first place was Just Plain Wrong (tm). I
> > had to suggest something :-)
> >
> > The other alternative is to have #ifdef's to replace the dlerror() call.
> > IMO, that would be even more wrong since you're splitting up DSO handling
> > between errorcodes.c and the dso/ directory.
> >
> > Whatever your solution, recognize that you've got two groups of code:
> >
> > 1) error string construction
> > 2) DSO loading
> >
> > Given that you are trying to insert DSO-specific stuff into (1), then you
> > have a problem if you try to keep (1) and (2) from talking with each
> > other. [my suggestion has (1) calling over to the (2) group]
> >
> > Cheers,
> > -g
> >
> > --
> > Greg Stein, http://www.lyra.org/
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
--
Greg Stein, http://www.lyra.org/
Re: building on Unix this a.m.
Posted by rb...@covalent.net.
The fact is, there are only two options right now for where to get the dso
error string from, errno and dlerror. errno is already taken care of, and
dlerror make sense where it is if it is the only other option.
Now, if/when Windows implements a dso feature, we can/should re-visit
this. The real solution IMNSHO, is to use a feature macro for APR
here. Basically allow DSO to be turned on/off from the configure
line. This way, when there is no DSO handling in Apache, this error
message changes. If there is DSO handling, we grab it from dlerror the
same way we are doing now.
The other fact is that this code was broken on Windows because that
feature macro doesn't exist, and this error isn't used on Windows. The
build on Unix is broken because we aren't using the right libraries, which
goes back to a configuration issue.
Ryan
> Fine, but using dlerror() in the first place was Just Plain Wrong (tm). I
> had to suggest something :-)
>
> The other alternative is to have #ifdef's to replace the dlerror() call.
> IMO, that would be even more wrong since you're splitting up DSO handling
> between errorcodes.c and the dso/ directory.
>
> Whatever your solution, recognize that you've got two groups of code:
>
> 1) error string construction
> 2) DSO loading
>
> Given that you are trying to insert DSO-specific stuff into (1), then you
> have a problem if you try to keep (1) and (2) from talking with each
> other. [my suggestion has (1) calling over to the (2) group]
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: building on Unix this a.m.
Posted by Greg Stein <gs...@lyra.org>.
On Fri, 26 May 2000 rbb@covalent.net wrote:
> > Fetching that string should be an APR-internal function from the dso/
> > area. Only the DSO modules are going to know how to fetch the string.
> >
> > There shouldn't be a HAVE_DLERROR, as all knowledge of that stuff "should
> > be" isolated to the dso/ directory.
>
> That's not the way anything in APR currently works. I haven't really
> figured out the best way to do this, but creating a new solution is
> sub-optimal IMHO.
Fine, but using dlerror() in the first place was Just Plain Wrong (tm). I
had to suggest something :-)
The other alternative is to have #ifdef's to replace the dlerror() call.
IMO, that would be even more wrong since you're splitting up DSO handling
between errorcodes.c and the dso/ directory.
Whatever your solution, recognize that you've got two groups of code:
1) error string construction
2) DSO loading
Given that you are trying to insert DSO-specific stuff into (1), then you
have a problem if you try to keep (1) and (2) from talking with each
other. [my suggestion has (1) calling over to the (2) group]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/