2015.06.24 15:26 "Re: [Tiff] CMake support for building libtiff", by Rhys Thomas

I've just posted a new set of patches against 4.0.4. If you could possibly retry with them, it might have cleared up some of the issues (I've fixed a few header/type-related bits).

I haven't exhaustively tested every combination. It's on my list though--I've just been limited by time. It took a good while just getting the basic build and tests working, so haven't tested (on Windows) with separate zlib/jpeg/jbig at this point. I've tested the functionality on BSD/Linux/MacOS X to be sure it works with various combinations of no/some/all optional libraries being used. One other area which might need tweaking is the detection of the Debug/Release version of the libtiff.dll when running tests in case it's not sufficiently flexible.

If the new patches don't help here it would certainly be useful to have more concrete details of exactly what you are linking aginst, how those libraries were built etc. so I can try to reproduce locally. If they were built against a different version of the runtime that might cause problems? (I'm afraid I'm still a relative beginner to building on Windows since my native territory is Unix, so I'm still learning the ins and outs of the nastiness.)

That does seem to have cleaned up quite a few problems. On my "dirty" system I still have some trouble compiling out of the box. Under Visual Studio 2008 32-bit the first errors that appear are relating to missing header files that should be present, including windows.h and stdio.h in the most of the projects. I can't see an obvious reason for this - the "Ignore standard include path" option is set to no.

The other three configurations (VS2008 64-bit, VS2012 32-bit and VS2012 64-bit) again do not compile out of the box on my "dirty" system. I get errors stating that "unistd.h" cannot be found, referenced from zconf.h in the GnuWin32 zlib installation. It does look like my installation of GnuWin32 is the reason behind this. I'm not sure what version I have. The version of zlib looks to be out-of-date, the header is copyright 1995-2005, whereas a later version that I have elsewhere is copyright 1995-2012 and this isn't the latest version. The old version contains a "#ifdef 1" in it, and this section is changed and commented out in the more recent version that I have. If I change the CMake options to point to the new version it compiles successfully. I successfully built and tested the VS2012 32-bit version with zlib support disabled (for some reason my zlib headers aren't all in the same directory) and a non-GnuWin32 version of libtiff.

I think that the reason why I was having success on the clean system was that I did not have any installation of zlib or libjpeg so CMake built a solution file without referring to them. Manually changing the CMake options to point at my own builds seems to result in successful builds. I have tended not to do an install any libraries that I have built. I may see if I can install a build of zlib to see what happens if I have some time to do so.

Rhys