2016.05.10 12:40 "Re: [Tiff] snprintf and MSVC 2015", by Edward Lam

On 09/05/2016 7:01 PM, Roger Leigh wrote:

OK. For clarity and consistency with the other defines, I think

#define HAVE_SNPRINTF 1

would be a bit better (adding 1 at the end)

I agree. Bob, could you make this minor change in CVS as well?

I've been able to reproduce it now, but the reason is defying
explanation. If I open a VS2015 native tools prompt and run nmake, it
now errors out just like your log, and the patch fixes it. However...
this is exactly what I was doing when it succeeded, and I'm still
building in a new checkout each time, so I'm unsure what the trigger is.

I think it will depend on the environment from which you ran your build tools because this behaviour depends on the Platform SDK version being used. In Visual Studio 2015, Microsoft has split out part of the C run-time into the Platform SDK as of Visual Studio 2015 called the Universal CRT, aka "ucrt". Try comparing the include paths and the value of the INCLUDE environment variable between where it builds and it doesn't build. Note that you will need to change tif_config.vc.h to comment out the fix if you're doing fresh checkouts.

The other potentially confounding factor here is that tif_config.h is copied from tif_config.vc.h only if it doesn't exist or is older.

 > The only situation I can see this maybe

failing is if you built with nmake, it generated a broken tif_config.h in the srcdir, and then you do an out-of-tree cmake build, and it generates a good tif_config.h in the builddir, but the one in the srcdir is used instead. If anyone is seeing a failure with cmake, could you retry in a clean checkout to see if that helps?

I have never used cmake for libtiff so I am certain it has nothing to do with a broken tif_config.h. As I previously mentioned, I run "nmake /f Makefile.vc clean" to ensure that tif_config.h (and all other generated files) is first deleted "in the tree".

I just tried rebuilding again with a fresh checkout and commented out the SNPRINTF define in tif_config.vc.h (since Bob had already checked in the fix). It fails to build in exactly the same way.

The only reason I see you succeeding is that you already had some tif_config.h lying around and/or you're using a different Platform SDK somehow.

Best Regards,

-Edward