Re: Compiling against external PCRE

Last message for now. Just to say that I have a single-architecture x86_64 Privoxy running with the same architecture of PCRE, so at least it can work and is relatively simple to set up. Now for the hard yards - programming a package generation framework that packs multiple single-architecture binaries and installs only the right ones.



On 2012-03-21, at 5:07 PM, Ian Silvester wrote:

> Curses!!
> 
> pcre's make uses certain flags (the -M ones) that are incompatible with building multi-architecture binaries :o(
> 
> The ramifications are that if I want to bundle PCRE, I'll either need to build three separate installers (one per architecture on which OS X runs - PPC, i386 and x86_64) or else add complexity that senses the target architecture and installs only the correct pcre binaries from a 'palette' of single-architecture choices.
> 
> The latter is naturally my preferred route, both because it'll mean less handle-turning each time a new privoxy version is released and also because there are some Maccies out there who no doubt have no clue what architecture(s) their machine supports. This is going to take some time, not least because I was considering adding such arch sensing so as to install a single-arch privoxy binary rather than the tri-arch one I do at the moment.
> 
> Watch this space (but don't hold your breath!)
> 
> Ian
> 
> 
> 
> On 2012-03-21, at 4:18 PM, Ian Silvester wrote:
> 
>> Never mind - it works equally well in CFLAGS.
>> 
>> This solved those problems, though the build still doesn't use the external pcre because the pcre make as it stands doesn't build 64 bit objects (my preferred target architecture). Easy enough to fix though.
>> 
>> Regardless, thanks for the pointer Fabian!
>> 
>> 
>> On 2012-03-21, at 3:11 PM, Ian Silvester wrote:
>> 
>>> Thanks for jogging my memory about the prior discussion Fabian!
>>> 
>>> Xcode bundles gcc 4.2.1 which (as you wrote previously) doesn't automatically search the sensible locations for header files. Indeed, the pcre make install puts the header files at /usr/local/include. Also in that prior discussion you quoted the following as your settings for LDFLAGS & CPPFLAGS:
>>> 
>>> LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include/ CC=... ./configure ...
>>> 
>>> One ignorant questions - why CPPFLAGS and not CFLAGS?
>>> 
>>> Ian
>>> 
>>> 
>>> On 2012-03-21, at 1:50 PM, Fabian Keil wrote:
>>> 
>>>> Ian Silvester <[email protected]> wrote:
>>>> 
>>>>> My next task is to create an OS X distribution with a more recent, external PCRE library bundled with it (on the basis that the vast majority of OS X Privoxy users won't have this library installed for themselves and hence there'll be no installation conflicts).
>>>>> 
>>>>> I've done the usual toolchain dance and now have the pcre binaries installed at /usr/local/lib, and have worked out from Privoxy's configure.in that I need the two header files pcre.h and pcreposix.h present in Privoxy's source directory. Nevertheless, autoconf still tells me the following:
>>>> 
>>>> Those headers don't need to be in Privoxy's source
>>>> directory as long as the compiler finds them.
>>>> 
>>>>> checking for pcre_compile in -lpcre... no
>>>>> checking for regcomp in -lpcreposix... yes
>>>>> checking pcreposix.h usability... no
>>>>> checking pcreposix.h presence... yes
>>>>> configure: WARNING: pcreposix.h: present but cannot be compiled
>>>>> configure: WARNING: pcreposix.h:     check for missing prerequisite headers?
>>>>> configure: WARNING: pcreposix.h: see the Autoconf documentation
>>>>> configure: WARNING: pcreposix.h:     section "Present But Cannot Be Compiled"
>>>>> configure: WARNING: pcreposix.h: proceeding with the preprocessor's result
>>>>> configure: WARNING: pcreposix.h: in the future, the compiler will take precedence
>>>>> checking for pcreposix.h... yes
>>>>> 
>>>>> It seems I have two problems:
>>>>> 
>>>>> 1. For reasons I cannot fathom, the first library check (pcre, pcre_compile,) fails to find the function pcre_compile in the library pcre. This function is present in both the bundled and manually-installed versions of pcre so I'm at a loss as to why this check fails.
>>>> 
>>>> Maybe the compiler doesn't look for pcre in the right places.
>>>> Copying the headers into Privoxy's source directory is not
>>>> necessarily sufficient for a compile and link test.
>>>> 
>>>>> 2. Whilst the second library check does succeed, the subsequent header check doesn't go so well. Whilst the header file is found, it seems (from the reading I've been doing about the "Present But Cannot Be Compiled" warning) that there is another header on which pcreposix.h depends, but I've no idea which this is.
>>>>> 
>>>>> Can anyone who has this working shed any light on either problem?
>>>> 
>>>> Unlike pcre_compile(), regcomp() is also POSIX standardized and
>>>> may be available in the system libc. It's not a big deal, but I
>>>> wouldn't rule out the possibility that autoconf is finding
>>>> the wrong one.
>>>> 
>>>> Getting the pcre_compile() check working might fix this as a side effect.
>>>> 
>>>>> Separately, apart from the concerns regarding bundling a library that the end user might already have (another version of) installed, are there any other reasons not to go this route? It seems to me that bundling a newer pcre is nothing but a good idea.
>>>> 
>>>> I have nothing to add since the last time we discussed the pros
>>>> and cons of bundling pcre.
>>>> 
>>>> Fabian
>>>> ------------------------------------------------------------------------------
>>>> This SF email is sponsosred by:
>>>> Try Windows Azure free for 90 days Click Here 
>>>> http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
>>>> Ijbswa-developers mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/ijbswa-developers
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here 
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> _______________________________________________
>>> Ijbswa-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/ijbswa-developers
>> 
>> 
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here 
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Ijbswa-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/ijbswa-developers
> 
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Ijbswa-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ijbswa-developers


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure