Doug MacEachern <[EMAIL PROTECTED]> writes:
> > 2) when it tries to link it gets pages and pages of these errors:
> >
> > gcc -DLINUX=2 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite `./apaci` \
> > -o httpd buildmark.o modules.o modules/perl/libperl.a
>modules/standard/libstandard.a main/libmain.a ./os/unix/libos.a ap/libap.a
>regex/libregex.a lib/expat-lite/libexpat.a -lm -lcrypt
> > modules/perl/libperl.a(mod_perl.o): In function `perl_shutdown':
>
> did you ever get this sorted out? this link line isn't even close to
> correct, how did you go about building, Makefile.PL options, etc??
We're fine now thanks, I'm sure I tried several times to rm -rf and start from
scratch with untar but obviously something wasn't working. I just gave up and
handed it to someone else to do, it worked first time for them.
I think the interdependence with the apache tree and the mod_perl tree just
makes things too complicated. I'm not unfamiliar with complicated building
software -- even fairly complex software, but mod_perl just plain won that
weekend, I conceded defeat.
It doesn't help that there are at least two completely different ways to build
each. I would suggest narrowing it down to just one right way to build apache.
If the shared module can't be made rock solid then I suppose one way for
shared module and one for compiling statically into apache. But I would
suggest throwing out the PREP_HTTPD and DO_HTTPD stuff and the option to not
use apaci.
Currently there are about three or four different instructions on how to build
mod_perl in the package and they all suggest following different procedures.
--
greg
