Re: Problem building with static pcre

On 2013-01-07, at 10:18 AM, Fabian Keil wrote:

> Ian Silvester <[email protected]> wrote:
> 
>>> 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!).
> 
> Given that using the internal pcre is what you want, explicitly
> setting --disable-dynamic-pcre seems like the way to go as that's
> what it there for.

Cool.

>>> 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!
> 
> I'm not sure I understand the license issues your are referring to.

Thanks for weighing in Fabian, it's been proven that I don't have a complete grasp of licensing implications ;o)

> I'm currently using pcre 8.32 which has a permissive license that
> allows distributing modified binaries even if the modifications
> aren't published at all.

I'm an idiot. I assumed pcre was GPLv2 and hence made some incorrect assumptions. In fact as you point out pcre uses BSD's license. That relieves the pressure somewhat, but I'll leave modifying the pcre build process as a battle for another day. Again, I think the Maccies'll just be happy to have a Privoxy package at all ;o) If any of them does log an issue that's related to down-level pcre then we can inform them of the issues then.

> The GPLv2 allows statically or dynamically linking Privoxy to a
> modified pcre library provided all the pcre modifications are
> available under a GPLv2-compatible license and their use is
> properly documented.

Well this is part of what puts me off. I wouldn't want to solely publish such pcre mods as part of the Privoxy project since we're downstream and I would expect they'd be of interest to other pcre-using projects that target OS X. When and if I modify the prce build environment I'll contribute it back to that project for publishing there. Once it's available there the following privoxy release can benefit from it, since I'm not keen on putting in duplicate effort to publish the modifications as part of privoxy. If of course it's not accepted by the pcre maintainers then I'd publish in the privoxy project.

Ian



> Whether or not the pcre project accepts the changes doesn't
> matter for the GPLv2 either.
> 
> Fabian
> ------------------------------------------------------------------------------
> 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