Bump to lipzip/rel-1-5-1/b95cf3fdd4c1271f922017f092d02a878873425c (#863)

[grendello]

Bump to lipzip/rel-1-5-1/b95cf3fdd4c1271f922017f092d02a878873425c (#863)

Main reason is to include fixes for a couple CVEs. Changes:

• 1.3.0
  • Support bzip2 compressed zip archives
  • Improve file progress callback code
  • Fix zip_fdopen()
  • CVE-2017-12858: Fix double free().
  • CVE-2017-14107: Improve EOCD64 parsing.
• 1.3.1
  • Install zipconf.h into ${PREFIX}/include
  • Add zip_libzip_version()
  • Fix AES tests on Linux
• 1.3.2
  • Fix bug introduced in last: zip_t was erroneously freed if zip_close()
    failed.
• 1.4.0
  • Improve build with cmake
  • Retire autoconf/automake build system
  • Add zip_source_buffer_fragment().
  • Add support to clone unchanged beginning of archive (instead of
    rewriting it). Supported for buffer sources and on Apple File System.
  • Add support for Microsoft Universal Windows Platform.
• 1.5.0
  • Use standard cryptographic library instead of custom AES
    implementation. This also simplifies the license.
  • Use clang-format to format the source code.
  • More Windows improvements.
• 1.5.1
  • Choose format of installed documentation based on available tools.
  • Fix visibility of symbols.
  • Fix zipcmp directory support.
  • Don’t set RPATH on Linux.
  • Use Libs.private for link dependencies in pkg-config file.
  • Fix build with LibreSSL.
  • Various bugfixes.

Additionally:

• make it possible to build Windows version of libzip on Linux with mingw (no
  mxe required)
• build on macOS for Windows with system/brew cmake
• export MACOSX_DEPLOYMENT_TARGET=10.11 in the top-level makefile to specify
  the minimum version of macOS we support. Without this it is possible that
  code built on 10.11 with Xcode targeting a newer version of the system will
  not work on macOS older than the version targetted by Xcode being used. For
  instance, if we build on macOS 10.11 with Xcode 8.2 (which targets macOS
  10.12) then the code which just built on 10.11 may not work on this very
  system - because it may use APIs available only starting from 10.12

[jonpryor]

The current macOS PR Build failure is because the resulting libzip.5.0.dylib file is built against Sierra (macOS 10.12), while the CI machine is running El Capitan (10.11). As such, the _clonefile symbol can't be found:

  Javac Task (TaskId:2997)
    StubSourceDirectory: obj/Debug/android/src (TaskId:2997)
...
dyld: lazy symbol binding failed: Symbol not found: _clonefile
  Referenced from: /Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android/libzip.5.0.dylib
  Expected in: /usr/lib/libSystem.B.dylib

The current thought is that if we export MACOSX_DEPLOYMENT_TARGET=10.11 it might make things work. This requires additional testing.

[grendello]

MACOSX_DEPLOYMENT_TARGET=10.11 didn't work as expected (as far as cmake is concerned) in that clonefile was still detected. Currently building is another attempt, this time to "poison" the cmake cache to make it think clonefile is absent. MACOSX_DEPLOYMENT_TARGET=10.11 remains in place, however, as it affects other native code built with Apple toolchains.

[jonpryor]

Why explicitly qualify cmake instead of relying on $PATH, as is done for macOS?

[grendello]

We also build cmake as part of mxe and I want to be explicit that we run (we MUST run) the system one because it's the "native" one and we're configuring a cross build using a "native" toolchain (mingw). Linux currently doesn't build mxe (Ubuntu and friends) but it's not unlikely that some distro will need to build it for one reason or another. I don't want to have any ambiguities