Re: Problem building with static pcre

> On 1/6/2013 10:34 PM, Ian Silvester wrote:
>> CFLAGS= -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 -mmacosx-version-min=10.6
> 
> Hi, Ian -
> 
> Any reason you need to specify a min version of 10.6?  Does it change 
> anything if you move to 10.5 or 10.4?
> 
> - David

It's a fair point actually - the static pcre package is intended to be 10.5 upwards compatible. Changing this did allow the compile, and the reason why supports the hypothesis I've put together (below). - the libpcre on the build environment is, of force, single architecture and is x86_64, whist the 10.5+ compile options are for i386 & x86_64, hence an extra configure test fails (checking for pcre_compile in -lpcre... no) and this is enough to deter the process from attempting to use libpcre.

This is why I've not come across this problem before - the packages I build for distribution neatly step around a bug in my build script - namely that if libpcre is installed and one attempts to build a single-architecture binary for the same architecture as that supported by libpcre the build will fail for the reasons I've outlined below.

> On 2013-01-07, at 12:39 AM, Lee wrote:
> 
>> ... I don't know what is being tested to check pcre.h usability.
> 
> configure should create a config.log that shows you how it tested.
> does that exist?

Yes, this exists but isn't much less mysterious than the configure script itself!


I think I've reasoned out what must be happening though:

- the build machine has libpcre installed
- configure finds libpcre installed and so proceeds as if to use it since it's architecture matches that we're building
- it find that the header and library are not in the path for gcc and hence marks it not usable
- the logic of the configure script however still decides that libpcre should be used

Unless someone can disprove this theory I'll just go ahead and use the explicit dynamic pcre disable (one wonders if it was added for just the above case!).

>> Ian Silvester <[email protected]> wrote:
>> 
>> So in the run-up to the 3.0.20 release I'm testing package builds,
>> and am tripping over a test in the configure script when trying to
>> build the binary with static pcre. Using the following invocation
>> against a completely vanilla checkout of current (on my build machine
>> that does have libpcre installed):
> 
> Can you clarify which pcre you are trying to statically
> link against and why?

The internal pcre, because by doing so I can make one multi-architecture privoxy binary that'll support powerpc, i386 & x86_64 on all versions of OS X 10.5 and above. In order to dynamically link to the latest external libpcre I would have to start hacking the libpcre build scripts in order to make it support building multi-architecture binaries. In my experience Mac users complain more about non-portability than they do about specific faults, and will not notice that they are not using the latest and greatest pcre. In the rare case of a Mac user who wants the 'best' result, they'll typically be savvy enough to go ahead and build libpcre for themselves and build their own Privoxy package to use it.

>> My issue is that I don't understand autoconf syntax so despite my best 
>> efforts to comprehend it I don't know what is being tested to check
>> pcre.h usability. I've worked around this by using the
>> --disable-dynamic-pcre configure option but it is a shame to have to
>> force it - I'd be happier if I could understand why the test fails.
>> 
>> Thanks for any pointers,
> 
> My impression is that our autoconf mess has been written with the
> assumptions that the best option is always dynamically linking to an
> external pcre, that nobody would ever want to statically link to an
> external pcre and that statically linking to the outdated internal pcre
> should only be used as fallback if no piece of an external pcre can
> be found and an external pcre can't be provided without a lot of pain.

See above - hacking libpcre's build script to support multi-architecture binaries is, for me at this stage of the game, a lot of pain.

> The --disable-dynamic-pcre flag is poorly worded and really means
> something like "statically link to the internal pcre no matter what
> else is available".

Sure, and I understood it as such despite the poor wording.

> To you and me statically linking to an external pcre might seem useful
> for some platforms, but it's currently intentionally not supported
> and --disable-dynamic-pcre by design is not supposed to help there.
> 
> I think it would be great if statically linking against an external
> pcre was supported, but it probably involves a fair number of autoconf
> changes and due to the risk of negatively affecting every platform it
> should probably wait until the next stable release.

So long as I can redistribute libpcre binaries I'm happy to stick with dynamic linking. I don't see a licensing issue with doing so, since I am not modifying the libpcre codebase in any way. Ironically if I were to make such modifications to support multi-architecture then licensing issues _would_ arise unless or until those changes were accepted back into the libpcre project and I would not be allowed to distribute the binaries I built!


Thanks for all your rapid and helpful input,

Ian



> 
> Lee
> 
> 
> On 1/6/13, Ian Silvester <[email protected]> wrote:
>> Hi all,
>> 
>> So in the run-up to the 3.0.20 release I'm testing package builds, and am
>> tripping over a test in the configure script when trying to build the binary
>> with static pcre. Using the following invocation against a completely
>> vanilla checkout of current (on my build machine that does have libpcre
>> installed):
>> 
>> CFLAGS= -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64
>> -mmacosx-version-min=10.6
>> LDFLAGS= -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64
>> -mmacosx-version-min=10.6
>> ./configure --with-user=_privoxy --with-group=_privoxy
>> 
>> I get the following (snippet of) output:
>> 
>> checking for pcre_compile in -lpcre... yes
>> checking pcre.h usability... no
>> checking pcre.h presence... yes
>> configure: WARNING: pcre.h: present but cannot be compiled
>> configure: WARNING: pcre.h:     check for missing prerequisite headers?
>> configure: WARNING: pcre.h: see the Autoconf documentation
>> configure: WARNING: pcre.h:     section "Present But Cannot Be Compiled"
>> configure: WARNING: pcre.h: proceeding with the preprocessor's result
>> configure: WARNING: pcre.h: in the future, the compiler will take
>> precedence
>> checking for pcre.h... yes
>> 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
>> checking for zlibVersion in -lz... yes
>> using libpcre
>> Enabling connection-sharing support.
>> configure: creating ./config.status
>> config.status: creating GNUmakefile
>> config.status: creating doc/source/ldp.dsl
>> config.status: creating config.h
>> 
>> Notice: building the privoxy software.
>> rm -f a.out actions.o cgi.o cgiedit.o cgisimple.o deanimate.o encode.o
>> errlog.o filters.o gateway.o jbsockets.o jcc.o list.o loadcfg.o loaders.o
>> miscutil.o parsers.o ssplit.o urlmatch.o  pcrs.o     privoxy default.action
>> \
>> 		`find . -name TAGS -o -name tags | grep -v .git` config.base config.tmp
>> gcc -c -pipe  -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64
>> -mmacosx-version-min=10.6   -Dunix -Wall   actions.c -o actions.o
>> In file included from actions.c:47:
>> project.h:75:22: error: pcre.h: No such file or directory
>> In file included from project.h:80,
>>                 from actions.c:47:
>> pcrs.h:94: error: expected specifier-qualifier-list before ‘pcre’
>> project.h:91:27: error: pcreposix.h: No such file or directory
>> In file included from actions.c:47:
>> project.h:369: error: expected specifier-qualifier-list before ‘regex_t’
>> actions.c: In function ‘update_action_bits_for_tag’:
>> actions.c:814: error: ‘struct url_spec’ has no member named ‘tag_regex’
>> actions.c:820: warning: implicit declaration of function ‘regexec’
>> actions.c:820: error: ‘struct url_spec’ has no member named ‘tag_regex’
>> make: *** [actions.o] Error 1
>> 
>> 
>> Obviously the failure is at "checking pcre.h usability... no", which results
>> in configure thinking that dynamic pcre is to be used ("using libpcre" later
>> in the configure output); the compile then fails since I'm not including the
>> path to the library's header (obviously enough, since I want to use static
>> pcre!).
>> 
>> My issue is that I don't understand autoconf syntax so despite my best
>> efforts to comprehend it I don't know what is being tested to check pcre.h
>> usability. I've worked around this by using the --disable-dynamic-pcre
>> configure option but it is a shame to have to force it - I'd be happier if I
>> could understand why the test fails.
>> 
>> Thanks for any pointers,
>> 
>> Ian
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. SALE $99.99 this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122412
>> _______________________________________________
>> Ijbswa-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/ijbswa-developers
>> 


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412