Re: PCRE library requirement

[Rik]

Richard Campbell wrote:
> 
> On Jan 31, 2011, at 3:05 PM, bpabbott wrote:
> 
>> On Jan 31, 2011, at 02:53 PM, Richard Campbell <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>>> On Jan 31, 2011, at 2:49 PM, Rik wrote:
>>>
>>> > bpabbott wrote:
>>> >> On Jan 31, 2011, at 12:55 PM, Rik <address@hidden
>>> <mailto:address@hidden>> wrote:
>>> >>
>>> >>> bpabbott wrote:
>>> >>>> On Jan 31, 2011, at 12:13 PM, Rik <address@hidden
>>> <mailto:address@hidden>
>>> >>> <mailto:address@hidden
>>> <mailto:address@hidden>>> wrote:
>>> >>>>
>>> >>>>> On Jan 31, 2011, at 10:33 AM, Richard Campbell wrote:
>>> >>>>>
>>> >>>>>>>
>>> >>>>>>> On Jan 31, 2011, at 10:17 AM, bpabbott wrote:
>>> >>>>>>>
>>> >>>>>>>>> On Jan 31, 2011, at 09:18 AM, Richard Campbell
>>> >>>>> <address@hidden <mailto:address@hidden>
>>> <mailto:address@hidden <mailto:address@hidden>>
>>> >>> <mailto:address@hidden <mailto:address@hidden>
>>> <mailto:address@hidden <mailto:address@hidden>>>> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> On Jan 31, 2011, at 8:10 AM, Ben Abbott wrote:
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>>> __gnuplot_get_var__ (gcf, "GPVAL_TERMINALS")
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Looks the same. I should add that I use this gnuplot with the
>>> >>>>> precompiled Octave.app and it works just fine. I built it from
>>> source
>>> >>>>> with no options.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> octave:2> __gnuplot_get_var__ (gcf, "GPVAL_TERMINALS")
>>> >>>>>>>>>>> ans = canvas cgm corel dpu414 dumb dxf eepic emf emtex
>>> >>>>> epslatex epson_180dpi epson_60dpi epson_lx800 fig gpic hp2623A
>>> hp2648
>>> >>>>> hp500c hpdj hpgl hpljii hppj imagen latex mf mif mp nec_cp6 okidata
>>> >>>>> pbm pcl5 postscript pslatex pstex pstricks qms regis starc svg
>>> >>>>> tandy_60dpi tek40xx tek410x texdraw tgif tkcanvas tpic unknown
>>> vttek
>>> >>>>> x11 xlib xterm
>>> >>>>>>>>>
>>> >>>>>>>>> Ok. I suspect that regexp isn't working correctly. First check
>>> >>>>> the regexp libs. Mine is below.
>>> >>>>>>>>>
>>> >>>>>>>>> octave:1> octave_config_info.REGEX_LIBS
>>> >>>>>>>>> ans = -L/sw/lib -lpcre
>>> >>>>>>>>>
>>> >>>>>>>>> Now, make sure this is where the problem is.
>>> >>>>>>>>>
>>> >>>>>>>>> octave:1> peaks
>>> >>>>>>>>> octave:2> terms = __gnuplot_get_var__ (gcf, "GPVAL_TERMINALS");
>>> >>>>>>>>> octave:3> terms = regexp (terms, '\b\w+\b', "match");
>>> >>>>>>>>> octave:4> disp(char(terms))
>>> >>>>>>>>> aqua
>>> >>>>>>>>> canvas
>>> >>>>>>>>> cgm
>>> >>>>>>>>> corel
>>> >>>>>>>>> dpu414
>>> >>>>>>>>> dumb
>>> >>>>>>>>> dxf
>>> >>>>>>>>> eepic
>>> >>>>>>>>> emf
>>> >>>>>>>>> emtex
>>> >>>>>>>>> epslatex
>>> >>>>>>>>> epson_180dpi
>>> >>>>>>>>> epson_60dpi
>>> >>>>>>>>> epson_lx800
>>> >>>>>>>>> fig
>>> >>>>>>>>> gif
>>> >>>>>>>>> gnugraph
>>> >>>>>>>>> gpic
>>> >>>>>>>>> hp2623A
>>> >>>>>>>>> hp2648
>>> >>>>>>>>> hp500c
>>> >>>>>>>>> hpdj
>>> >>>>>>>>> hpgl
>>> >>>>>>>>> hpljii
>>> >>>>>>>>> hppj
>>> >>>>>>>>> imagen
>>> >>>>>>>>> jpeg
>>> >>>>>>>>> latex
>>> >>>>>>>>> lua
>>> >>>>>>>>> mf
>>> >>>>>>>>> mif
>>> >>>>>>>>> mp
>>> >>>>>>>>> nec_cp6
>>> >>>>>>>>> okidata
>>> >>>>>>>>> pbm
>>> >>>>>>>>> pcl5
>>> >>>>>>>>> pdf
>>> >>>>>>>>> pdfcairo
>>> >>>>>>>>> png
>>> >>>>>>>>> pngcairo
>>> >>>>>>>>> postscript
>>> >>>>>>>>> pslatex
>>> >>>>>>>>> pstex
>>> >>>>>>>>> pstricks
>>> >>>>>>>>> qms
>>> >>>>>>>>> regis
>>> >>>>>>>>> rgip
>>> >>>>>>>>> starc
>>> >>>>>>>>> svg
>>> >>>>>>>>> tandy_60dpi
>>> >>>>>>>>> tek40xx
>>> >>>>>>>>> tek410x
>>> >>>>>>>>> texdraw
>>> >>>>>>>>> tgif
>>> >>>>>>>>>
>>> >>>>>>>>> Assuming that the regexp command does not give the proper
>>> >>> result ...
>>> >>>>>>>>>
>>> >>>>>>>>> In /usr/lib, I see the following pcre libs.
>>> >>>>>>>>>
>>> >>>>>>>>> libpcre.0.0.1.dylib
>>> >>>>>>>>> libpcre.0.dylib
>>> >>>>>>>>> libpcre.dylib
>>> >>>>>>>>> libpcreposix.0.0.0.dylib
>>> >>>>>>>>> libpcreposix.0.dylib
>>> >>>>>>>>> libpcreposix.dylib
>>> >>>>>>>>>
>>> >>>>>>>>> I'm guessing you are configured with libpcre.dylib. Try
>>> >>>>> switching to libpcreposix.dylib.
>>> >>>>>>>>>
>>> >>>>>>>>> Ben
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>
>>> >>>>>>> It works! So PCRE needs to be listed as 'required', apparently.
>>> >>>>> 1/31/11
>>> >>>>>
>>> >>>>> Octave could move this way and just require PCRE, but I would be
>>> >>>>> interested
>>> >>>>> to know where the actual problem call to regexp lies. Earlier,
>>> I did a
>>> >>>>> fair bit of work converting the calls to regexp in the code to
>>> be both
>>> >>>>> POSIX and PCRE compliant. It might be that just a simple tweak is
>>> >>>>> required. For example, the regexp call that I saw briefly in
>>> one of the
>>> >>>>> e-mails was '/\b\w+\b/' which is in PCRE syntax. The equivalent in
>>> >>> POSIX
>>> >>>>> would be '/\<\w+\</'.
>>> >>>>>
>>> >>>>> --Rik
>>> >>>>
>>> >>>> Rik,
>>> >>>>
>>> >>>> Will you be submitting a changeset?
>>> >>>
>>> >>> I can if I know where the problem lies. What file did you find
>>> the "bad"
>>> >>> regexp in?
>>> >>>
>>> >>> I did do a grep through the entire codebase before, but that is a
>>> slow way
>>> >>> to find the problem.
>>> >>>
>>> >>> --Rik
>>> >>
>>> >> It is in ...
>>> >>
>>> >> .../scripts/plot/private/__gnuplot_has_terminal__.m
>>> >>
>>> >> Ben
>>> >>
>>> > The regular expression '\b\w+\b' can be simplified to just '\w+'.
>>> However,
>>> > I'd still like Richard to run a test if possible. It would seem
>>> from this
>>> > chart (http://www.regular-expressions.info/refflavors.html) that
>>> even '\w+'
>>> > is not supported by POSIX regular expressions. It appears that the
>>> reason
>>> > this code works on most UNIX boxes without PCRE is that those
>>> machines have
>>> > GNU libraries. Thus, not having PCRE is not the equivalent of
>>> POSIX, but
>>> > rather equals GNU regular expressions support. So, I would have Richard
>>> > try the following in an Octave built without PCRE.
>>> >
>>> > str = "a ab abc"
>>> > results = regexp (str, '\w+', "match")
>>> >
>>> > If that fails because the actual libraries are truly POSIX
>>> compliant then I
>>> > think we should make PCRE a requirement. It is widely available and a
>>> > number of patterns in the code use the very convenient '\s' or '\w'
>>> > patterns rather than character classes.
>>> >
>>> > --Rik
>>>
>>> Okay, how do I force it to build without PCRE now that PCRE is on the
>>> machine?
>>>
>>> Campbell
>>  
>> hmmm. I had the impression that the pcre libs were always present.
>> Were the pcre libs not already in /usr/lib?
>>
>> Ben
>>
>>
>>
> Ben, you're right. There is a PCRE in /usr/lib that appears to have come
> with OSX, and one in /usr/local/lib that I compiled earlier today. For
> some reason Octave totally ignored the one in /usr/lib at configure time.
> 
> So it's not a matter of making it a requirement - it's a matter of
> figuring out why ./configure didn't see it.
Usually there are two packages for a library.  One supplies just the
runtime library and is for programs that have already been built.  The
second package is usually named library-dev and supplies things like header
files necessary to actually compile programs against the library.  It
sounds like you need the latter so that configure can find pcre.h.

However, without installing the pcre-dev you should be able to run the test
I was proposing, and then install pcre-dev and see if it fixes the
configure issue.

--Rik