Apothecary: Poco 1.5.3+

[bakercp]

Static libs, headers and apothecary formulas for architectures included:

• OSX FAT (32 bit w/ libstdc++ and 64 bit w/ libc++)
• iOS FAT (armv7, armv7s, arm64, i386 and x86_64 w/ libc++)
• Android - armeabi
• Android - armeabi-v7a
• Android - x86
• Linux (32 bit)
• Linux (64 bit)
• Linux Armv6l
• Linux Armv7l
• VS 2012
• win_cb / mingw32

All of these static libs were created using the apothecary formula in this branch.

From the $OF_ROOT/scripts/apothecary directory, I ran:

./apothecary update poco

This compiles the static libs according to the recipe (poco.sh) and copies the headers / static libs into place.

One thing to note -- this command will attempt also copy the headers, which may give you copy errors if the headers are already in place.

I chose poco release 1.5.3-release because it is the most recent "official" release without picking an arbitrary commit.

Currently we are using https://github.com/bakercp/poco/releases/tag/poco-apothecary-1.5 which happens to be the current develop head of Poco (as of 6 October, 2014).

Additionally, @arturoc I took care of the obnoxious X509Certificate.h header error wherein the that class' verify method conflicted with an OSX macro found in <AssertMacros.h>. You'll find the solution (which doesn't require the manual addition of the #ifdef verify #undef verify #endif stuff in the commit log and in ofContstants.h.

[bakercp]

One note -- in OSX, I'm getting a strange error when using existing FreeImage libs alongside these new Poco libs.

I get a crash with this error:

libc++abi.dylib: terminating with uncaught exception of type char const*
(lldb) 

This occurs when executing this line in ofImage

bmp = FreeImage_Load(fif, fileName.c_str());

Apparently there is a SIGABRT called on the .c_str(). Strangely debug messages all around the call report a correct contents and correctly terminated c_string returned by the method ... so my hope is that this will be resolved when we upgrade FreeImage. If anybody wants to hack on this fork and see what they can make of it, I'd be very appreciative.

[ofTheo]

is this good to merge in?

[ofTheo]

ps - should we make an issue in this repo for tracking which libs still need building?

[bakercp]

I think we should wait until we get the rest of the libs, because of the additional header files / updates required for all platforms.

[bakercp]

@danoli3 Let's try a rebuild with your update poco changes. I just updated the formula to match my tag. If we can confirm this is working on all platforms, I'll scrub this pull request clean of all old libs and resubmit with all credits.

The only lingering issue I'm wondering about is the strange PNG failure on OSX. I'm hopeful that your poco changes may fix that too :)

Otherwise, I think there is something funny happening in FreeImage that will need further investigation.

[bakercp]

Sadly, it doesn't appear that the FreeImage poco issue was resolved ... :/

[danoli3]

Ah I see, yes Poco/PDF has a version of libpng.
API/ABI issues sounds like a stdc++ string going into a libc++ area (and thus the system doesn't know if it should reference count), so something like that might be fixed when all compiled... but if you are testing against compiled version of FreeImage then maybe the following should fix it:

Add HPDF_NOPNGLIB=1 or export HPDF_NOPNGLIB=1 before the build. This will stop the building of the libpng part of Poco/PDF

[danoli3]

Also I've been testing the iOS Scripts on http://github.com/danoli3/apothecary-den (Travis doesn't mind drinking our potions)

[bakercp]

OK! We're almost there ... so @danoli3 @ofTheo @arturoc the OSX libpng issue is fixed if the PDF component of Poco is removed altogether.

Basically the Poco::PDF package is just a thin wrapper around http://libharu.org which is a nice PDF (write only) lib for writing reports, etc. In the Poco context it is primarily used for database query reports output, etc.

It turns out that the Poco::PDF package comes with a bundled libpng and zlib, which was somehow causing the problems. My only guess at this point is that somehow the C-source for the bundled libpng was causing problems ...

Since we already have PDF output support via Cairo and we didn't officially have support Poco::PDF previously, I'm going to omit it from the builds so we don't have to worry about it. Further, Poco doesn't really even include Poco::PDF in any of their documentation (and it's been in there since 1.3ish) so, I don't think we'll be missing out.

[bakercp]

@danoli3 Did you link your ios libs against the latest apothecary openssl libs?

[ofTheo]

+1 to your suggestion @bakercp - I think that makes sense.

[danoli3]

Yeah iOS is compiled against latest OpenSSL libs from the formula.

On Wednesday, October 8, 2014, Christopher Baker notifications@github.com
wrote:

@danoli3 https://github.com/danoli3 Did you link your ios libs against
the latest apothecary openssl libs?

—
Reply to this email directly or view it on GitHub
#3116 (comment)
.

[danoli3]

Just noting that we are omitting CppUnit in the new Formula/Libs, as discussed in this issue : #3116

[bakercp]

This PR is being closed in favor of #3116. Huge thanks to @danoli3 for cherry-picking.