VS 2015 compiling cocos2d-x 3.3 error "fatal error C1189: #error: Macro definition of snprintf conflicts with Standard Library function declaration"
Asked Answered
S

3

37

When I compile cocos2d-x (version 3.3) using visual studio 2015, an error occured, saying:

fatal error C1189: #error: Macro definition of snprintf conflicts with Standard Library function declaration (编译源文件 ..\base\s3tc.cpp)

The source code is:

#ifdef snprintf
    #error Macro definition of snprintf conflicts with Standard Library 
             function declaration
#endif

Anybody can tell me what's wrong?

Schmuck answered 3/1, 2015 at 11:48 Comment(0)
S
62

Until now, Many libraries & programs used snprintf() function by defining it as _snprintf(), since _snprintf() was supported.

#define snprintf _snprintf

Finally, Visual Studio 14 defines snprintf()!

Since, snprintf() is now officially supported. We should never #define it.

Doing it will overshadow new snprintf() function defined in stdio.h.

To restrict that, this is added in stdio.h

#ifdef snprintf
    #error: Macro definition of snprintf conflicts with Standard Library function declaration”
#endif

Hence, your code doesn't compile.

It is true that on all previous versions of Visual Studio, you must use _snprintf() function. But VS 2014 onwards you should not #define it with _snprintf().

Somewhere in your code or most likely in cocos headers, this is done and hence the error.

Check that and remove that #define.

snprintf() is part of C99 specifications.

To enable C99 support

add this in your program

#if _MSC_VER>=1900
#  define STDC99
#endif

In case you don't know what _MSC_VER macro values are

...
MSVC++ 14.0 _MSC_VER == 1900 (Visual Studio 2015)
MSVC++ 12.0 _MSC_VER == 1800 (Visual Studio 2013)
MSVC++ 11.0 _MSC_VER == 1700 (Visual Studio 2012)
MSVC++ 10.0 _MSC_VER == 1600 (Visual Studio 2010)
MSVC++ 9.0  _MSC_VER == 1500 (Visual Studio 2008)
MSVC++ 8.0  _MSC_VER == 1400 (Visual Studio 2005)
MSVC++ 7.1  _MSC_VER == 1310 (Visual Studio .NET 2003)
MSVC++ 7.0  _MSC_VER == 1300
MSVC++ 6.0  _MSC_VER == 1200
MSVC++ 5.0  _MSC_VER == 1100
MSVC++ 4.0  _MSC_VER == 1000
MSVC++ 2.0  _MSC_VER ==  900
MSVC++ 1.0  _MSC_VER ==  800
C/C++  7.0  _MSC_VER ==  700
C      6.0  _MSC_VER ==  600
Stocktaking answered 3/1, 2015 at 12:25 Comment(6)
Please note that #define snprintf _snprintf should never be used. It is unsafe as _snprintf() doesn't guarantee null-termination unlike C99's snprintf(). There are also other differences.Hodess
@cremno, Is this your comment or answer? I think you have misunderstood the whole point I am making here.Stocktaking
It's just a comment. Your answer is fine.Hodess
What about adding a stub to define the old name to allow old libs (that otherwise should work with any compiler version) to work?Theadora
I have this problem in a public library that needs to keep working with older VS versions. I wrapped the offending #define sprintf with #if _MSC_VER<1900 ... #endif and yes I know this is obvious to many of you.Wenonawenonah
Thanks for the solution.If I compile libs in VS 2013 it is not working in VS 2015. Same goes the other way. Can we make changes in lib source so one lib can work on both versions of VS?Clupeoid
R
5

Just find the definition of snprintf in your code and undefine it while on VS2015.
Something like:

#if _MSC_VER < 1900 //vs2015 already have this function
#define snprintf _snprintf_s 
#endif
Retentive answered 7/7, 2017 at 3:19 Comment(0)
M
3

user1 is right

But even if you fix the problem this way, you'll probably face linker problems with prebuilt libraries.

The way to avoid this is to change platform toolset on all projects to Visual Studio 2013 (v120)

And in linker/input propry page add libcmt.lib to Ignore Specific Default libraries: libcmt.lib;libcmtd.lib;...

Monocot answered 10/1, 2015 at 9:22 Comment(3)
OP and others who look up this issue will likely not have the luxury to stick with VS2013 just to avoid an error.Larrainelarrie
@Larrainelarrie , user1185287 is not suggesting using VS2013, but to change the toolset used to compile, from the project properties (General Tab) directly from VS2015Sprite
I gotcha. The point, in its essence still stands, though. We all eventually have to "trade-up" :)Larrainelarrie

© 2022 - 2024 — McMap. All rights reserved.