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