You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Issac Goldstand <ma...@beamartyr.net> on 2002/12/02 18:41:44 UTC
[users@httpd] freelists in Apache 2
Can someone please explain to me what freelists are and how to go about
using them? Just when I thought I was getting some handle on some of the
filter tutorials, I find that the tutorials are from befoer freelists were
added to the bucket brigade API and now I'm very stuck and confused...
PS I'm cc-ing the dev list in the hopes of 1) getting an answer from someone
who knows about freelists and 2) to suggest that you add some *basics* on
the filter API to the site, and better yet, some basics on the freelists to
the brigade API source (this is the only thing I can't figure out - the
parameters aren't mentioned in the source comments in most places)
Thanks,
Issac
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: configure scripts broken
Posted by bu...@kattare.com.
Greetings,
Well, here's the output of 'head httpd.conf'. ;-)
---Begin Clip---------------------
#
# 5/98 -- Kattare Original
# 8/00 -- DSO Support Added
# 10/01 -- 1.3.22
# 10/02 -- 1.3.27
#
ServerType standalone
ServerRoot "/usr/local/apache"
---End Clip---------------------
Cheers,
~Ethan B.
Quoting Joe Schaefer <jo...@sunstarsys.com>:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
> > burnside@kattare.com writes:
> >
> > > LoadModule perl_module libexec/libperl.so
> > >
> > > Which tells it to look in the apache root /usr/local/apache,
> then
> > > works relative from there. If I'm not mistaken, this is also
> the
> > > recommended mode of operation regarding DSO modules.
> > >
> > > To get the apreq compile to work I had to change it to:
> > >
> > > LoadModule perl_module
> /usr/local/apache/libexec/libperl.so
> > >
> > > So that's about the gist of it. I don't know what the fix
> is, but
> > > I think you probably just have to add a check for 'apache-root
> +
> > > perl_module' to the current check for 'perl_module'. If that
> makes
> > > sense?
> >
> > It makes sense, thanks for the details. Stay tuned...
>
> Have you tried moving your
>
> ServerRoot /usr/local/apache
>
> line around in httpd.conf? I think it needs to be above the
> LoadModule
> directive in order to use a relative path for perl_module.
>
> In any case, I don't see how this would make the slightest
> difference in libapreq's *compilation*, which was one of
> the problems listed in an earlier post (bad Apache::src
> => no typemap for Apache::Table => Request.xs build fails).
>
> Does anybody else know what's going on here?
>
> --
> Joe Schaefer
>
--------------------------
Ethan Burnside - Founder
Kattare Internet Services
http://www.kattare.com
--------------------------
Re: configure scripts broken
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> burnside@kattare.com writes:
>
> > LoadModule perl_module libexec/libperl.so
> >
> > Which tells it to look in the apache root /usr/local/apache, then
> > works relative from there. If I'm not mistaken, this is also the
> > recommended mode of operation regarding DSO modules.
> >
> > To get the apreq compile to work I had to change it to:
> >
> > LoadModule perl_module /usr/local/apache/libexec/libperl.so
> >
> > So that's about the gist of it. I don't know what the fix is, but
> > I think you probably just have to add a check for 'apache-root +
> > perl_module' to the current check for 'perl_module'. If that makes
> > sense?
>
> It makes sense, thanks for the details. Stay tuned...
Have you tried moving your
ServerRoot /usr/local/apache
line around in httpd.conf? I think it needs to be above the LoadModule
directive in order to use a relative path for perl_module.
In any case, I don't see how this would make the slightest
difference in libapreq's *compilation*, which was one of
the problems listed in an earlier post (bad Apache::src
=> no typemap for Apache::Table => Request.xs build fails).
Does anybody else know what's going on here?
--
Joe Schaefer
Re: configure scripts broken
Posted by Joe Schaefer <jo...@sunstarsys.com>.
burnside@kattare.com writes:
[...nice summary...]
> - Our default line in our httpd.conf that includes the mod_perl dso is:
>
> LoadModule perl_module libexec/libperl.so
>
> Which tells it to look in the apache root /usr/local/apache, then
> works relative from there. If I'm not mistaken, this is also the
> recommended mode of operation regarding DSO modules.
>
> To get the apreq compile to work I had to change it to:
>
> LoadModule perl_module /usr/local/apache/libexec/libperl.so
>
> So that's about the gist of it. I don't know what the fix is, but
> I think you probably just have to add a check for 'apache-root +
> perl_module' to the current check for 'perl_module'. If that makes
> sense?
It makes sense, thanks for the details. Stay tuned...
--
Joe Schaefer
Re: configure scripts broken
Posted by bu...@kattare.com.
Joe,
I'm afraid I don't really have much background with apreq. So I
probably can't help much in fixing it, but here's a (hopefully) better
description of the problem.
- apache, mod_perl, & perl are custom installations. no out of the box
distro configurations here.
apache:
CFLAGS="$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \
./configure \
--prefix=/usr/local/apache \
--sbindir=/usr/local/apache/sbin \
--server-uid=www \
--server-gid=www \
--enable-suexec \
--suexec-caller=www \
--suexec-docroot=/nfs \
--suexec-logfile=/log/suexec_log \
--suexec-uidmin=100 \
--suexec-gidmin=100 \
--enable-module=most \
--enable-shared=max \
--add-module=mod_frontpage.c
mod_perl:
perl Makefile.PL \
USE_APXS=1 \
WITH_APXS=/usr/local/apache/sbin/apxs \
EVERYTHING=1
- If I remeber right, the apreq 'perl Makefile.PL' worked just fine. I
had to pass the path to my apache includes, but that's about it.
- Then doing a 'make' or 'make install' would go for a bit, but
ultimately fail stating that Apache__Table was missing from the mod_perl
installation.
- I quoted 'nm' results earlier in the thread. Basically it showed no
'Apache__Table' in the httpd binary, but it was present in the mod_perl
DSO module.
- Our default line in our httpd.conf that includes the mod_perl dso is:
LoadModule perl_module libexec/libperl.so
Which tells it to look in the apache root /usr/local/apache, then
works relative from there. If I'm not mistaken, this is also the
recommended mode of operation regarding DSO modules.
To get the apreq compile to work I had to change it to:
LoadModule perl_module /usr/local/apache/libexec/libperl.so
So that's about the gist of it. I don't know what the fix is, but I
think you probably just have to add a check for 'apache-root +
perl_module' to the current check for 'perl_module'. If that makes sense?
Cheers,
~Ethan B.
Quoting Joe Schaefer <jo...@sunstarsys.com>:
> burnside@kattare.com writes:
>
> > The configure/make scripts are broken.
> >
> > If you use DSO's and you don't include the full path to
> > the mod_perl DSO file in libexec, then it refuses to
> > compile/install saying it can't find Apache__Table.
> >
> > A little bit of relative-path intelligence in the next
> > version would go a long way.
>
> [...]
>
> I've been trying to follow the discussion, but I can't
> figure out exactly what problem is being discussed. If
> you're doing a perl build of libapreq, libapreq gets its
> Makefile information from the Apache::src module. For some
> reason, it seems a few OS vendors fail to install this
> module properly, which is why the normal thing we suggest
> users do is just rebuild/install modperl themselves. That
> way they get a working Apache::src, and Apache:::Request
> should build ok then.
>
> If you've figured out some better way to handle this,
> by all means please continue working on it! If you
> submit a patch, and it works ok on all platforms, it'll
> definitely go into the upcoming release of 1.1.
>
> Our current build/test system needs lots of work,
> and any contribution will make a big difference
> to the current user community. If you need help
> fixing something, please don't hesitate to ask.
>
> --
> Joe Schaefer
>
--------------------------
Ethan Burnside - Founder
Kattare Internet Services
http://www.kattare.com
--------------------------
Re: configure scripts broken
Posted by Joe Schaefer <jo...@sunstarsys.com>.
burnside@kattare.com writes:
> The configure/make scripts are broken.
>
> If you use DSO's and you don't include the full path to
> the mod_perl DSO file in libexec, then it refuses to
> compile/install saying it can't find Apache__Table.
>
> A little bit of relative-path intelligence in the next
> version would go a long way.
[...]
I've been trying to follow the discussion, but I can't
figure out exactly what problem is being discussed. If
you're doing a perl build of libapreq, libapreq gets its
Makefile information from the Apache::src module. For some
reason, it seems a few OS vendors fail to install this
module properly, which is why the normal thing we suggest
users do is just rebuild/install modperl themselves. That
way they get a working Apache::src, and Apache:::Request
should build ok then.
If you've figured out some better way to handle this,
by all means please continue working on it! If you
submit a patch, and it works ok on all platforms, it'll
definitely go into the upcoming release of 1.1.
Our current build/test system needs lots of work,
and any contribution will make a big difference
to the current user community. If you need help
fixing something, please don't hesitate to ask.
--
Joe Schaefer
configure scripts broken
Posted by bu...@kattare.com.
The configure/make scripts are broken.
If you use DSO's and you don't include the full path to the mod_perl
DSO file in libexec, then it refuses to compile/install saying it can't
find Apache__Table.
A little bit of relative-path intelligence in the next version would go
a long way.
Or at least something in the documentation about the issue. ;-)
Cheers,
~Ethan B.
--------------------------
Ethan Burnside - Founder
Kattare Internet Services
http://www.kattare.com
--------------------------
> I gave nm a whirl. Here's the results:
>
> salvation:# nm httpsd | grep boot_Apache
> nm: /usr/local/apache/sbin/httpsd: no symbols
>
> salvation:# nm libperl.so | grep boot_Apache
> 0006b32c T boot_Apache
> 00072530 T boot_Apache__Connection
> 0006d60c T boot_Apache__Constants
> 0007427c T boot_Apache__File
> 0006f224 T boot_Apache__Log
> 0006e390 T boot_Apache__ModuleConfig
> 00073424 T boot_Apache__Server
> 00075788 T boot_Apache__Table
> 00070c30 T boot_Apache__URI
> 00071750 T boot_Apache__Util
>
> I'm guessing that the result from the httpsd is because we're
> using
> the mod_perl dso. Thus the second nm I used the mod_perl loadable
> module. As you can see, it's in there. It would appear that the
> config
> tool for apache::request is broken. Maybe it only checks the
> httpsd
> file and not the DSO? Or maybe it looks for an httpd file when ours
> is
> named httpsd?
>
> I'm cc'ing this (and thus the entire thread) to the apreq-dev
> mailing list. Hopefully they'll have some insight. ;-)