Existing zlib should be used whenever possible

[UnitedMarsupials-zz]

All modern Unix-like systems (BSDs, MacOS, Linux, Solaris) already come with zlib. Same is usually true about OpenSSL.

When building lepton on such systems, the dependencies/ folder should be completely ignored. In fact, it should be possible to not have it at all. The fix will be three-fold:

• teach configure.ac and Makefile.am to not freak out, when dependencies/ does not exist
• teach the same to set the -I, the -L and the -l flags properly
• change the sources to stop #includeing by full path (../../dependencies/...) and refer simply to header-file names: #include <md5.h>. The compiler will find the headers based on the -I flags set by configure

[danielrh]

when running this at scale we want to be super meticulous about running it with a pinned version of zlib. We don't want to have any surprises if some package gets an unexpected patch and suddenly the md5sum of a file might change when run through the same compression pass because zlib decided to repack things differently.

We could, however, add a configure flag to use the system zlib, I suppose.

[UnitedMarsupials-zz]

We don't want to have any surprises if some package gets an unexpected patch

I understand, but this is dangerous thinking -- where do you stop? Should every zlib-using software package bundle its own copy "just in case"? The approach escalates very quickly -- how about bundling a specific compiler?

We could, however, add a configure flag to use the system zlib, I suppose.

As a minimum, yes. I still think, it ought to be the default setting. If you are worried about regression-tests failing because of zlib-differences, make zlib's version (obtained by calling zlibVersion() at run time) part of the test-log -- the way you already output git's commit-tag.

[danielrh]

There's now a configure option to use the system crypto libs and libz fd84210340dcd64ee2738a9159034d6fb36bcdd3 enjoy!