On Mon, Jan 08, 2018 at 02:22:21PM +0000, Stuart Henderson wrote:
> On 2018/01/08 02:27, Jeremie Courreges-Anglas wrote:
> > On Sun, Jan 07 2018, Stuart Henderson <s...@spacehopper.org> wrote:
> > > On 2018/01/07 18:56, Chris Bennett wrote:
> > >> I did find this problem with using clang.
> > >>
> > >> https://marc.info/?l=apache-modperl&m=143930336811571&w=2
> > >> http://clang.llvm.org/compatibility.html#inline
> > >>
> > >> Not sure if useful
> > >>
> > >> Chris Bennett
> > >>
> > >
> > > It is, thanks. Please give this a spin.
> >
> > With this mod_perl loads fine in a quick test. Probably not good for
> > upstream as it's a rather big hammer, but ok jca@ if it also works for
> > Chris.
>
> IMHO mod_perl doesn't make sense any more. Something via fastcgi makes a
> lot more sense than pulling Perl into the webserver's address space. But
> since we already shipped it broken in 6.2 let's provide a crutch if we
> can.
>
> That said: any OKs to remove ap2-mod_perl? (Or I will accept NAKs in
> the form of a diff to add a suitable MAINTAINER :-)
>
I don't object. This diff "seems" to work.
mod_perl has been altered in a huge way.
The manual pages are only partly rewritten.
I am at a total loss of how to do something as simple as $l =
$q->param("lang");
So far all I can find is $string_of_params = $r->args();
Which is worthless except when params only have one value!
And why should I have to do something as idiotic as turn a string into
a hash? Ugh!
The mod_perl developers already have a long history of crappy manual
and guides.
Why they decided to make such massive changes and assume everyone can
guess their way through is unbelieveable.
Anyway, thanks.
I guess I'm one of the last OpenBSD users to use mod_perl.
Oh well, not our fault.
Chris Bennett
