On Jun 29, 2017, at 9:09 AM, Daniel Dumitriu <daniel.dumit...@gmail.com> wrote: > > After googling it [1], it looks like this is due to mismatch between > zlib and fossil compiler options for runtime selection
Yes, your diagnosis and proposed fix are correct. It is important to build all parts of an executable with the same runtime options under Visual C++. > what could be a clean solution here (without > touching zlib's Makefile)? If compat/zlib is currently vanilla zlib, a “vendor branch” should be created, then when compat/zlib is updated from upstream, the changes should be checked in on the vendor branch and the diffs merged into trunk. As long as upstream zlib doesn’t touch the Makefile near the Fossil-specific edits to Makefile.in, this will result in clean merges. And if upstream does change CFLAGS or similar, the merge error will highlight the conflict, which will generally be easily handled manually. That, or convince upstream zlib to change the build option. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
