Re: pcre module help

[Vincent Stemen <zsh@xxxxxxxxxxx>]

On Sun, Jun 20, 2004 at 03:37:11PM -0400, Clint Adams wrote:
> > I tried this under zsh-4.2.0 on FreeBSD with the pcre module statically
> > linked in.
> 
> Is the zsh binary actually linked against libpcre?
> Does configure detect the existence of pcre_compile() and pcre_exec()?
> You shouldn't get the "not available on this system" message unless it
> didn't find one of them.

Looks like you are right.  I thought it would automatically use it if
it was available on the system and I enabled it in config.modules.
Especially since it still went through pcre detection, because I saw
output from configure that said,

checking pcre.h usability... yes
checking pcre.h presence... yes
checking for pcre.h... yes

However, further down I disovered it said,

checking for pcre_compile... no
checking for pcre_study... no
checking for pcre_exec... no

because it did not use -lpcre.

Enabling it with the configure option, --enable-pcre, seems to have
corrected that, although I have not recompiled and tested it yet.


> >    pcre_compile: not available on this system
> > 
> >    pcre_match: not available on this system
> 
> > 
> >    # if [[ $PATH -pcre-match '^/.*local' ]]; then echo "matched"; fi
> > 
> >    zsh: unrecognized condition: `$PATH'
> > 
> >    # pcre_compile "^/.*local"
> > 
> >    pcre_compile: not available on this system
> > 
> >    # if [[ $PATH -pcre-match '^/.*local' ]]; then echo "matched"; fi
> > 
> >    -- shell crashes leaving a core file --
> > 
> > The shell crashing is consistent when I try to use -pcre-match after
> > attempting to run pcre_compile.  Also, the -pcre-match method is not
> > mentioned in the zshmodules manual.
> 
> Could you send a gdb backtrace to zsh-workers?

I would still think it should not crash because of a missing feature.
If you still would like a backtrace to find that problem, I will try
to get around to recompiling it with debugging turned on and generate
one for you.  Just let me know.

Vincent

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
Read how Network Solutions (NSI) was involved in stealing our domain name.
http://www.InetAddresses.net