divelogs download fails

[Dirk Hohndel]

> On Aug 1, 2018, at 8:37 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
>>> On 1. Aug 2018, at 09:26, Miika Turkia <miika.turkia at gmail.com> wrote:
>>> 
>>> We have received the same/similar error report. https://github.com/Subsurface-divelog/subsurface/issues/1534
>>> 
>>> At least my current understanding is that this is Mac specific, and thus I cannot debug it at all. However, if it still works with 4.8.0 and does not work with 4.8.1, then the probelm should be on Subsurface side. If I am not entirely mistaken, there has been some changes in both codebase/libraries and the tooling that is used to produce the binaries for Mac. So could be either one causing the issue.
>>> 
>> 
>> I can reproduce this with the official 4.8.1 binary but not with what can build from current master on my Mac.
>> 
>> From the error message it appears the problem is that around lines 888pp of subsurfacewebservices.cpp
>> 
>> #if defined(Q_OS_UNIX) && defined(LIBZIP_VERSION_MAJOR)
>> 	int duppedfd = dup(zipFile.handle());
>> 	struct zip *zip = NULL;
>> 	if (duppedfd >= 0) {
>> 		zip = zip_fdopen(duppedfd, 0, &errorcode);
>> 		if (!zip)
>> 			::close(duppedfd);
>> 	} else {
>> 		QMessageBox::critical(this, tr("Problem with download"),
>> 				      tr("The archive could not be opened:\n"));
>> 		return;
>> 	}
>> #else
>> 	struct zip *zip = zip_open(QFile::encodeName(zipFile.fileName()), 0, &errorcode);
>> #endif
>> 	if (!zip) {
>> 		char buf[512];
>> 		zip_error_to_str(buf, sizeof(buf), errorcode, errno);
>> 		QMessageBox::critical(this, tr("Corrupted download"),
>> 				      tr("The archive could not be opened:\n%1").arg(QString::fromLocal8Bit(buf)));
>> 		zipFile.close();
>> 		return;
>> 	}
>> 
>> zip_open() in the else clause fails. This sounds like a libzip (possibly packaging) problem.
>> 
> 
> Hmm. The official app is built on this computer - and it uses the "right" libzip. But as we all expected,
> I can reproduce the problem. Haven't figured out what causes it, but at least I have a good starting
> point where to look.

This is a weird one. Somehow libzip-1.2.0 mis-compiles on this Mac

MacOS 10.11.6
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0

I tried a few things to make this work but finally gave up and blindly switched to libzip 1.5.1
The libzip team switched to also develop on GitHub and deprecated the autotools build, so I adjusted our tooling to clone from GitHub and use cmake. And on the first attempt this worked.
So instead of worrying about it too much, I'll simply call this the solution (let's see if this goes and bites us in the butt elsewhere).

Continuous build binaries are compiling so we can check if the GitHub/Travis builds are fixed as well.

/D