Includes the patches from macports and fixes an issue with the
`otool -L` output that was causing g-ir-scanner to fail.
The paths in the macports patches have been modified so that they
will work with `patches` in nix (an extra directory level was
added).
The changes are a bit too big to include it here in the commit message,
so if you want the details of what changed, please visit this URL:
http://leptonica.org/source/version-notes.html
I have also provided openjpeg, giflib and libwebp as dependencies so
that Leptonica is able to read/write those file formats.
Additionally I've added a patch that uses pkgconfig to resolve all
dependencies (except giflib), because unlike AC_CHECK_LIB() the
PKG_CHECK_MODULES() macro defines *_LIBS variables to include the linker
search path.
Unfortunately that patch alone is not enough, because the *_LIBS
variable are substituted by the upstream configure.ac to *not* include
the linker search paths, so we need to remove the AC_SUBST() calls
within PKG_CHECK_MODULES().
The only dependency that's not yet using PKG_CHECK_MODULES() is giflib,
because giflib doesn't have a pkg-config description file, therefore
we're using substituteInPlace to insert the linker search path after the
lept.pc file was generated by configure.
Another thing that we no longer need is the dependency on libpng version
1.2, because Leptonica now also works with more recent libpng versions.
Tested by building the package itself and also the following packages
that immediately depend on leptonica:
* k2pdfopt
* tesseract
* jbig2enc
All of these packages succeeded to build on x86_64-linux.
The main reason why I'm bumping Leptonica to version 1.74.1 is that we
need at least version 1.74 to bump Tesseract to the latest upstream
version.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Not sure if the things I made optional on Darwin are really worth keeping
at all, but I don't have a Linux box handy so I'm minimizing potential
damage.
Including apple_sdk.sdk is generally a recipe for a bad time on LLVM 3.8
and above, since you end up with bad headers in the wrong place that hurt
the new libc++ in 3.8 and above. In this case, qt only wanted the super-
generic SDK for CUPS headers, which we can just depend on directly now.