On 12/23/2013 10:05 PM, Fernando de Oliveira wrote:
> Em 23-12-2013 14:27, Igor Živković escreveu:
>> On 12/23/2013 05:20 PM, Fernando de Oliveira wrote:
>>> Em 23-12-2013 12:14, i...@higgs.linuxfromscratch.org escreveu:
>>>> Author: igor
>>>> Date: Mon Dec 23 07:14:25 2013
>>>> New Revision: 12437
>>>>
>>>> Log:
>>>> remove pcre from wireshark dependencies
>>>
>>> Did you remove because it is required by other dependencies? Please,
>>> tell which one. I am asking it because I need to improve (a lot) my
>>> knowledge about dependencies.
>>
>> I couldn't find in the source code where it's used directly. It might be
>> used via GLib though.
>>
>
> Thanks, Igor,
>
> I also could not find pcre at the beginning, but then I did:
>
> {{{
> $ find -iname \*pcre\*
> ./epan/ftypes/ftype-pcre.c
> $ grep -ri pcre
> ...
> Makefile.nmake:    rm -r -f pcre-6.4
> Makefile.nmake:    rm -r -f pcre-7.0
> tools/fix-encoding-args.pl:           FT_PCRE
> AUTHORS:      Display filter operator: matches (PCRE syntax)
> ocbook/dfilter2xml.pl:        'FT_PCRE',              'Perl Compatible 
> Regular Expression',
> packaging/nsis/uninstall.nsi:Delete "$INSTDIR\pcrepattern.3.txt"
> packaging/rpm/SPECS/wireshark.spec.in:#BuildRequires: pcre-devel
> rawshark.c:        case FT_PCRE:
> rawshark.c:            return "FT_PCRE";
> epan/enterprise-numbers:      dan&blipcreative.com
> epan/CMakeLists.txt:  ftypes/ftype-pcre.c
> epan/wslua/wslua_proto.c:     ftypes.UINT_BYTES, ftypes.IPv4, ftypes.IPv6,
> ftypes.IPXNET, ftypes.FRAMENUM, ftypes.PCRE, ftypes.GUID
> epan/wspython/wspy_dissector.py:FT_PCRE,
> epan/ftypes/Makefile.in:      ftype-none.lo ftype-pcre.lo ftype-string.lo
> ftype-time.lo \
> epan/ftypes/Makefile.in:      ftype-pcre.c    \
> epan/ftypes/Makefile.in:@AMDEP_TRUE@@am__include@
> @am__quote@./$(DEPDIR)/ftype-pcre.Plo@am__quote@
> epan/ftypes/ftypes.h: FT_PCRE,        /* a compiled Perl-Compatible Regular
> Expression object */
> epan/ftypes/ftype-bytes.c:    /* fv_b is always a FT_PCRE, otherwise the
> dfilter semcheck() would have
> epan/ftypes/ftype-bytes.c:    if (strcmp(fv_b->ftype->name, "FT_PCRE") != 0) {
> epan/ftypes/ftype-bytes.c:            regex,                  /* Compiled 
> PCRE */
> epan/ftypes/ftype-string.c:   /* fv_b is always a FT_PCRE, otherwise the
> dfilter semcheck() would have
> epan/ftypes/ftype-string.c:   if (strcmp(fv_b->ftype->name, "FT_PCRE") != 0) {
> epan/ftypes/ftype-string.c:                   regex,          /* Compiled 
> PCRE */
> epan/ftypes/Makefile.common:  ftype-pcre.c    \
> epan/ftypes/ftype-tvbuff.c:   /* fv_b is always a FT_PCRE, otherwise the
> dfilter semcheck() would have
> epan/ftypes/ftype-tvbuff.c:   if (strcmp(fv_b->ftype->name, "FT_PCRE") != 0) {
> epan/ftypes/ftype-tvbuff.c:                   regex,          /* Compiled 
> PCRE */
> epan/ftypes/ftypes.c: ftype_register_pcre();
> epan/ftypes/ftype-pcre.c: * $Id: ftype-pcre.c 48424 2013-03-19 19:02:25Z
> etxrab $
> epan/ftypes/ftype-pcre.c:/* Perl-Compatible Regular Expression (PCRE)
> internal field type.
> epan/ftypes/ftype-pcre.c: * compilation and studying of a PCRE pattern
> in dfilters.
> epan/ftypes/ftype-pcre.c:/* Generate a FT_PCRE from a parsed string pattern.
> epan/ftypes/ftype-pcre.c:/* Generate a FT_PCRE from an unparsed string
> pattern.
> epan/ftypes/ftype-pcre.c: * and we want to store the compiled PCRE RE
> object into the value. */
> epan/ftypes/ftype-pcre.c:ftype_register_pcre(void)
> epan/ftypes/ftype-pcre.c:    static ftype_t pcre_type = {
> epan/ftypes/ftype-pcre.c:        FT_PCRE,        /* ftype */
> epan/ftypes/ftype-pcre.c:        "FT_PCRE",      /* name */
> epan/ftypes/ftype-pcre.c:    ftype_register(FT_PCRE, &pcre_type);
> epan/ftypes/ftypes-int.h:void ftype_register_pcre(void);
> epan/proto.c:                 case FT_PCRE:
> epan/proto.c: { FT_PCRE,          "FT_PCR"           },
> epan/proto.c:         case FT_PCRE:
> epan/proto.c:                 /* FT_PCRE never appears as a type for a 
> registered
> field. It is
> epan/dissectors/packet-dcom.c:        guint32 u32RPCRes;
> epan/dissectors/packet-dcom.c:                        
> hf_dcom_variant_rpc_res, &u32RPC
> ...
> }}}
>
> After that, I thought I should leave it as optional. So I was wrong,
> doing that, you think?
>

Yep, the only relevant part is:

packaging/rpm/SPECS/wireshark.spec.in:#BuildRequires:   pcre-devel

which suggests that it might have been used in the past.

-- 
Igor Živković
http://www.slashtime.net/
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to