Re: Problem building with static pcre

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.

> > 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.

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.

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.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlDq50UACgkQSMVSH78upWODlQCdHlIx4TmyZErfsCSIGOzwGWn4
ynYAn2Xyq1nGdA8gw0QIq14vL6ZqbJLp
=Xat2
-----END PGP SIGNATURE-----