You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@opengroup.org> on 1997/06/04 16:36:04 UTC
Re: [STATUS] Wed Jun 4 08:10:42 EDT 1997
Jim Jagielski <ji...@jaguNET.com> wrote:
> Problems and Patches
> ====================
>
> * Weird interaction under Linux using BrowserMatch. Putting
> $REGLIB after $LIBS causes it not to work. Possible name-
> space problems.
> Status: Looking into it. We may need to go back to the
> old order for 1.2
I dug around with nm for a while last night, I could not see where
apache's libregex.a and libperl would have a conflict. So, at the
moment, mod_perl's Makefile.PL will swap the link order back to what
it was in b10, unless mod_php is configured into apache. If mod_php
is present, it doesn't touch the link order, but sets Rule WANTHSREGEX
to 'no'. I don't think this is right, Rasmus, what do you suggest
should happen if mod_php is configured in?
-Doug
Re: [STATUS] Wed Jun 4 08:10:42 EDT 1997
Posted by ra...@bellglobal.com.
> I dug around with nm for a while last night, I could not see where
> apache's libregex.a and libperl would have a conflict. So, at the
> moment, mod_perl's Makefile.PL will swap the link order back to what
> it was in b10, unless mod_php is configured into apache. If mod_php
> is present, it doesn't touch the link order, but sets Rule WANTHSREGEX
> to 'no'. I don't think this is right, Rasmus, what do you suggest
> should happen if mod_php is configured in?
Ack! If you set WANTHSREGEX to 'no' and mod_php has been compiled to
use hsregex, mod_php is going to die badly.
What you really need is an order that looks like this:
mod_php.o -lphp -lregex mod_perl.o -lperl(?)
-Rasmus