# Compile error 9.0RC3, VS 2017, Windows 10, snprintf

**URL:** https://discourse.vtk.org/t/compile-error-9-0rc3-vs-2017-windows-10-snprintf/3136
**Category:** Support
**Created:** [April 23, 2020, 8:29pm UTC](https://discourse.vtk.org/t/compile-error-9-0rc3-vs-2017-windows-10-snprintf/3136 "2020-04-23T20:29:57Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![biagas](https://discourse.vtk.org/user_avatar/discourse.vtk.org/biagas/32/7380_2.png) [@biagas](https://discourse.vtk.org/u/biagas)
#### Post date: [April 23, 2020, 8:29pm UTC](https://discourse.vtk.org/t/compile-error-9-0rc3-vs-2017-windows-10-snprintf/3136/1 "2020-04-23T20:29:57Z")

</div>

I am using CMake 3.12.2, VS 2017 15.9.22 on a Windows 10 machine.  
When I compile, I get errors in libxml2 and tiff:

```auto
Macro redefinition of 'snprintf' conflicts with Standard Library definition.

```

I have traced it to ThirdParty/libxml2/vtklibxml/CMakeLists.txt, which calls

```auto
check_sybmol_exists(snprintf "${LIBXML_INCLUDES}" HAVE_SNPRINTF)

```

However, LIBXML\_INCLUDES does not list stdio.h which is where snprint is defined, so HAVE\_SNPRINTF is set to false.

when ThirdParty/tiff/vtktiff/CMakeLists also checks for snprintf with its call to

```auto
check_symbol_exists(snprintf "stdio.h" HAVE_SNPRINTF)

```

which should succeed, it doesn’t, because HAVE\_SNPRINTF has already been set.

There is a build path where the check for ‘snprintf’ happens before libxml’s check, then things work.  
I think that is when vtkhdf5 is included in the build. For my use case, I am not using vtkhdf5.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [April 24, 2020, 1:51pm UTC](https://discourse.vtk.org/t/compile-error-9-0rc3-vs-2017-windows-10-snprintf/3136/2 "2020-04-24T13:51:27Z")

</div>

> [@biagas](#):
>
> There is a build path where the check for ‘snprintf’ happens before libxml’s check, then things work.  
> I think that is when vtkhdf5 is included in the build. For my use case, I am not using vtkhdf5.

Hmm. That would explain why we don’t see it on our builds. Please file an issue; I’ll try and get to it early next week.