Trying to build libxml2 from source from the current master branch:
https://github.com/GNOME/libxml2
I'm working in Windows 10 environment and trying to build the msvc variant. Following the readme here:
https://github.com/GNOME/libxml2/tree/master/win32
My steps for building are:
1. Open Developer Command Prompt for VS 2017 as admin.
2. Navigate to libxml2\win32.
3. Running the following command: cscript configure.js compiler=msvc prefix=c:\opt include=c:\opt\include lib=c:\opt\lib debug=yes
4. nmake /f Makefile.msvc
5. Getting the following: LINK : fatal error LNK1104: cannot open file 'iconv.lib'
Note that i do have the required environment variables set for the libiconv that I use for other projects in my LIB and LIBPATH variable, I also tried adding to PATH even though it's not nececcasry as VS environment cmd reads the LIB and LIBPATH.
(C:\projects\libraries\libiconv\1.9.2-vc110-32bit\Release\lib)
I'm thinking the reason I get this linking error, is because libiconv needs to be build under msvc141(VS17) too?
https://git.savannah.gnu.org/git/libiconv.git
That would cool if it's not the case, as I might need to change a lot in the project if things are updated there, because when I tried building libxml2 with VS12 and VS15 developer command prompt, I got different error in code compatibility, as I guess the owner of the repo doesn't support these versions anymore or they just work in VS17 environment.
Thanks in advance for the help!
Full output:
C:\projects\libraries\libxml\2.7.8-vc110-32bit\Release\bin\libxmlNEW\libxml2\win32>nmake /f Makefile.msvc
Microsoft (R) Program Maintenance Utility Version 14.12.25835.0
Copyright (C) Microsoft Corporation. All rights reserved.
if not exist bin.msvc mkdir bin.msvc
if not exist int.msvc mkdir int.msvc
cl.exe /EP /nologo /I..\include /D "NOLIBTOOL" /D "_REENTRANT" libxml2.def.src > int.msvc\libxml2.def
libxml2.def.src
rc -Fo int.msvc\libxml2.res libxml2.rc
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation. All rights reserved.
cl.exe /nologo /D "_WINDOWS" /D "_MBCS" /D "NOLIBTOOL" /W3 /wd4244 /wd4267 /MD /I.. /I..\include /Ic:\opt\include /D "_REENTRANT" /D "HAVE_WIN32_THREADS" /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /D "_DEBUG" /Od /Z7 /Foint.msvc\ /c ..\buf.c ..\c14n.c ..\catalog.c ..\chvalid.c ..\debugXML.c ..\dict.c ..\DOCBparser.c ..\encoding.c ..\entities.c ..\error.c ..\globals.c ..\hash.c ..\HTMLparser.c ..\HTMLtree.c ..\legacy.c ..\list.c ..\nanoftp.c ..\nanohttp.c ..\parser.c ..\parserInternals.c ..\pattern.c ..\relaxng.c ..\SAX2.c ..\SAX.c ..\schematron.c ..\threads.c ..\tree.c ..\uri.c ..\valid.c ..\xinclude.c ..\xlink.c ..\xmlIO.c ..\xmlmemory.c ..\xmlreader.c ..\xmlregexp.c ..\xmlmodule.c ..\xmlsave.c ..\xmlschemas.c ..\xmlschemastypes.c ..\xmlunicode.c ..\xmlwriter.c ..\xpath.c ..\xpointer.c ..\xmlstring.c
buf.c
c14n.c
catalog.c
chvalid.c
debugXML.c
dict.c
DOCBparser.c
encoding.c
entities.c
error.c
globals.c
hash.c
HTMLparser.c
HTMLtree.c
legacy.c
list.c
nanoftp.c
..\nanoftp.c(927): warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings
C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\um\winsock2.h(2218): note: see declaration of 'gethostbyname'
..\nanoftp.c(929): warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings
C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\um\winsock2.h(2218): note: see declaration of 'gethostbyname'
nanohttp.c
parser.c
parserInternals.c
Generating Code...
Compiling...
pattern.c
relaxng.c
SAX2.c
SAX.c
schematron.c
threads.c
tree.c
uri.c
valid.c
xinclude.c
xlink.c
xmlIO.c
xmlmemory.c
xmlreader.c
xmlregexp.c
xmlmodule.c
xmlsave.c
xmlschemas.c
xmlschemastypes.c
xmlunicode.c
Generating Code...
Compiling...
xmlwriter.c
xpath.c
xpointer.c
xmlstring.c
Generating Code...
link.exe /nologo /VERSION:2.9 /LIBPATH:bin.msvc /LIBPATH:c:\opt\lib /DEBUG /DLL /IMPLIB:bin.msvc\libxml2.lib /OUT:bin.msvc\libxml2.dll int.msvc\buf.obj int.msvc\c14n.obj int.msvc\catalog.obj int.msvc\chvalid.obj int.msvc\debugXML.obj int.msvc\dict.obj int.msvc\DOCBparser.obj int.msvc\encoding.obj int.msvc\entities.obj int.msvc\error.obj int.msvc\globals.obj int.msvc\hash.obj int.msvc\HTMLparser.obj int.msvc\HTMLtree.obj int.msvc\legacy.obj int.msvc\list.obj int.msvc\nanoftp.obj int.msvc\nanohttp.obj int.msvc\parser.obj int.msvc\parserInternals.obj int.msvc\pattern.obj int.msvc\relaxng.obj int.msvc\SAX2.obj int.msvc\SAX.obj int.msvc\schematron.obj int.msvc\threads.obj int.msvc\tree.obj int.msvc\uri.obj int.msvc\valid.obj int.msvc\xinclude.obj int.msvc\xlink.obj int.msvc\xmlIO.obj int.msvc\xmlmemory.obj int.msvc\xmlreader.obj int.msvc\xmlregexp.obj int.msvc\xmlmodule.obj int.msvc\xmlsave.obj int.msvc\xmlschemas.obj int.msvc\xmlschemastypes.obj int.msvc\xmlunicode.obj int.msvc\xmlwriter.obj int.msvc\xpath.obj int.msvc\xpointer.obj int.msvc\xmlstring.obj int.msvc\libxml2.res wsock32.lib ws2_32.lib iconv.lib kernel32.lib
LINK : fatal error LNK1104: cannot open file 'iconv.lib'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.12.25827\bin\HostX86\x86\link.exe"' : return code '0x450'
Stop.
Note for future readers.
There is a way to build libxml2 without iconv dependency.
For that you need to use:
cscript configure.js compiler=msvc prefix=c:\opt include=c:\opt\include lib=c:\opt\lib debug=yes iconv=no
first, you need to make sure all these packages are build under same arch, which is either all x86 or x64, then libxml2's makefile don't recognize custom INCLUDE and LIB folders, you need to add those folder's into INCLUDE and LIB enviroment variables.
set INCLUDE=%INCLUDE%;<your include dir>
set LIB=%LIB%;<your lib dir>
which should let you compile.
This is basically the same question as [SO]: C2491: 'std::numpunct<_Elem>::id' : definition of dllimport static data member not allowed [closed], but considering the following facts:
That (on my opinion) is a perfectly valid question (according to [SO]: How to create a Minimal, Complete, and Verifiable example), I really don't know why some users felt the urge of closing it
The answer marked as a solution provides guidelines the for fixing the error (in general), but doesn't apply to current case, and certainly, doesn't fix it,
please don't close it or mark it as a duplicate (at least, not without carefully reading and understanding it).
main.cpp:
#include <sstream>
//#define THROW_C2491
#if defined(THROW_C2491)
typedef int CharType;
#else
typedef char CharType;
#endif
int main() {
std::basic_stringstream<CharType> stream;
CharType c = 0x41;
stream << c;
return 0;
}
The code is slightly modified (simplified), and fails to compile if THROW_C2491 is defined:
xlocnum(294): error C2491: 'std::numpunct<_Elem>::id': definition of dllimport static data member not allowed
Output:
E:\Work\Dev\StackOverflow\q048716223>"c:\Install\x86\Microsoft\Visual Studio Community\2015\vc\vcvarsall.bat" amd64
E:\Work\Dev\StackOverflow\q048716223>
E:\Work\Dev\StackOverflow\q048716223>"c:\Install\x86\Microsoft\Visual Studio Community\2015\vc\bin\amd64\cl.exe" /GS /W3 /Zc:wchar_t /ZI /Gm /Od /Zc:inline /fp:precise /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /MDd /EHsc /nologo -c "src\main.cpp"
main.cpp
E:\Work\Dev\StackOverflow\q048716223>echo %errorlevel%
0
E:\Work\Dev\StackOverflow\q048716223>
E:\Work\Dev\StackOverflow\q048716223>"c:\Install\x86\Microsoft\Visual Studio Community\2015\vc\bin\amd64\cl.exe" /GS /W3 /Zc:wchar_t /ZI /Gm /Od /Zc:inline /fp:precise /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /MDd /EHsc /nologo -c "src\main.cpp" /D "THROW_C2491"
main.cpp
c:\install\x86\microsoft\visual studio community\2015\vc\include\xlocnum(294): warning C4273: 'id': inconsistent dll linkage
c:\install\x86\microsoft\visual studio community\2015\vc\include\xlocnum(120): note: see previous definition of 'public: static std::locale::id std::numpunct<int>::id'
c:\install\x86\microsoft\visual studio community\2015\vc\include\xlocnum(120): note: while compiling class template static data member 'std::locale::id std::numpunct<_Elem>::id'
with
[
_Elem=CharType
]
c:\install\x86\microsoft\visual studio community\2015\vc\include\xlocnum(1261): note: see reference to function template instantiation 'const _Facet &std::use_facet<std::numpunct<_Elem>>(const std::locale &)' being compiled
with
[
_Facet=std::numpunct<CharType>,
_Elem=CharType
]
c:\install\x86\microsoft\visual studio community\2015\vc\include\xlocnum(1255): note: while compiling class template member function 'std::ostreambuf_iterator<_Elem,_Traits> std::num_put<_Elem,std::ostreambuf_iterator<_Elem,_Traits>>::do_put(_OutIt,std::ios_base &,_Elem,bool) const'
with
[
_Elem=CharType,
_Traits=std::char_traits<CharType>,
_OutIt=std::ostreambuf_iterator<CharType,std::char_traits<CharType>>
]
c:\install\x86\microsoft\visual studio community\2015\vc\include\ostream(305): note: see reference to class template instantiation 'std::num_put<_Elem,std::ostreambuf_iterator<_Elem,_Traits>>' being compiled
with
[
_Elem=CharType,
_Traits=std::char_traits<CharType>
]
c:\install\x86\microsoft\visual studio community\2015\vc\include\ostream(291): note: while compiling class template member function 'std::basic_ostream<_Elem,_Traits> &std::basic_ostream<_Elem,_Traits>::operator <<(int)'
with
[
_Elem=CharType,
_Traits=std::char_traits<CharType>
]
e:\work\dev\stackoverflow\q048716223\src\main.cpp(16): note: see reference to function template instantiation 'std::basic_ostream<_Elem,_Traits> &std::basic_ostream<_Elem,_Traits>::operator <<(int)' being compiled
with
[
_Elem=CharType,
_Traits=std::char_traits<CharType>
]
c:\install\x86\microsoft\visual studio community\2015\vc\include\istream(939): note: see reference to class template instantiation 'std::basic_ostream<_Elem,_Traits>' being compiled
with
[
_Elem=CharType,
_Traits=std::char_traits<CharType>
]
c:\install\x86\microsoft\visual studio community\2015\vc\include\sstream(574): note: see reference to class template instantiation 'std::basic_iostream<_Elem,_Traits>' being compiled
with
[
_Elem=CharType,
_Traits=std::char_traits<CharType>
]
e:\work\dev\stackoverflow\q048716223\src\main.cpp(14): note: see reference to class template instantiation 'std::basic_stringstream<CharType,std::char_traits<_Elem>,std::allocator<_Elem>>' being compiled
with
[
_Elem=CharType
]
c:\install\x86\microsoft\visual studio community\2015\vc\include\xlocnum(294): error C2491: 'std::numpunct<_Elem>::id': definition of dllimport static data member not allowed
with
[
_Elem=CharType
]
E:\Work\Dev\StackOverflow\q048716223>echo %errorlevel%
2
Notes:
Everything is VStudio 2015 specific, but the problem is reproducible using VStudio 2017, VStudio 2013, VStudio 2010 (of course, the line numbers differ). However, it works using VStudio 2005
I chose to paste the compiler commands(s) and output(s) from the cmdline, instead of placing pictures with compiler flags and output (from VStudio IDE), so it's easier to reproduce (if anyone is willing to try)
The compiler flags are defaults from an Application (.exe) VStudio project (Win32), except some irrelevant path related ones (e.g. .pch file and other such crap), that I stripped out
Compiles only if CharType is char (or any of the narrow character types, as a matter of fact) or wchar_t. Disabling [MS.Docs]: /Zc:wchar_t (wchar_t Is Native Type) adds unsigned short to the list (which seems natural)
Compiles without problems under Lnx (Ubtu 16 x64) / g++ (gcc 5.4.0)
[MS.Docs]: Compiler Error C2491 is pretty straightforward, I am familiar with it, there are some answers (e.g. [SO]: Linker error when calling a C function from C++ code in different VS2010 project (#CristiFati's answer), [SO]: Excel VBA, Can't Find DLL Entry Point from a DLL file (#CristiFati's answer)) to back me up.
Considering the above notes, I know that it's something that has to do with Win's way (limitation?) of handling chars, but I don't see any (immediate) connection between the code and the error. Nothing regarding this behavior on [MS.Docs]: basic_stringstream Class. I (shallowly) browsed the involved standard include headers, but I didn't get to the bottom of it so far. Am I missing smth extremely obvious?
Other references (same or similar error, but none containing a valid fix):
[SO]: VC++: Code works in VS2010 and breaks in VS2013
[MS.MSDN]: VS2010 error C2491: 'std::numpunct<_Elem>::id while using std::basic_fstream in c++/cli
[DeveloperIT]: std::basic_stringstream won't compile with MSVC 10
[itgo]: visual c++ - VC++: Code works in VS2010 and breaks in VS2013
It is worth mentioning that the end goal is to build some 3rd-party software that instantiates some 32 bit char based streams.
Start notes:
I am using VStudio Community 2015 (v14.0.25431.01 Update 3). Version is important here, since standard header files might change across versions (and line numbers might differ)
Created [MSDN]: Compile error for STL (stream) containers in Visual Studio
Approaches:
Quick (shallow) investigation
On VStudio IDE double click, on the 2nd note in the Output window (after attempting to compile the file), and from there repeated RClicks on relevant macros, and from the context menu choosing Go To Definition (F12):
xlocnum (#120): (comment is part of the original file/line)
__PURE_APPDOMAIN_GLOBAL _CRTIMP2_PURE static locale::id id; // unique facet id
yvals.h: (#494):
#define _CRTIMP2_PURE _CRTIMP2
crtdefs.h (#29+):
#ifndef _CRTIMP2
#if defined CRTDLL2 && defined _CRTBLD
#define _CRTIMP2 __declspec(dllexport)
#else
#if defined _DLL && !defined _STATIC_CPPLIB
#define _CRTIMP2 __declspec(dllimport) // #TODO - cfati: line #34: Here is the definition
#else
#define _CRTIMP2
#endif
#endif
#endif
As seen, __declspec(dllimport) is defined on line #34. Repeating the process on the _DLL macro, yielded no result. Found on [MSDN]: Predefined Macros:
_DLL Defined as 1 when the /MD or /MDd (Multithreaded DLL) compiler option is set. Otherwise, undefined.
I thought of 2 possible ways to go on (both resulting in a successful build):
Use static version of CRT Runtime ([MSDN]: /MD, /MT, /LD (Use Run-Time Library)). I don't consider it a viable option, especially when the project consists of .dlls (and it does): bad things can happen (e.g. [SO]: Errors when linking to protobuf 3 on MSVC 2013, or even nastier ones can occur at runtime)
Manually #undef _DLL (in main.cpp, before any #include). This is a lame workaround (gainarie). It builds fine, but tampering with these things could (and most likely will) trigger Undefined Behavior at runtime
None of these 2 options was fully satisfactory, so:
Going a (little) bit deeper
Tried to simplify things even more (main.cpp):
#include <sstream>
//typedef unsigned short CharType; // wchar_t unsigned short
#define CharType unsigned short
int main() {
std::basic_stringstream<CharType> stream;
CharType c = 0x41;
stream << c;
return 0;
}
Notes:
Replaced typedef by #define (to strip out new type definition complexity)
Switched to unsigned short which is wchar_t's definition (/Zc:wchar_t-) to avoid any possible type size / alignment differences
"Compiled" the above code with [MSDN]: /E (Preprocess to stdout) and [MSDN]: /EP (Preprocess to stdout Without #line Directives) (so that the warnings/errors only reference line numbers from current file):
Generated preprocessed files (using each flag froma bove): ~1MB+ (~56.5k lines)
The only difference in the files was the #define (wchar_t vs. unsigned short) somewhere at the very end
Compiling the files (shockingly :)) yielded the same result: the wchar_t one compiled while the unsigned short failed with the same error
Added some #pragma message statements (yes, they are handled by the preprocessor, but still) in the file that fails (before each warning/note), noticed some difference between the 2 #defines, but so far unable to figure out why 1
While browsing the generated file(s), noticed a template<> struct char_traits<char32_t> definition, so I gave it a try, and it worked (at least the current program compiled) 1 (and, as expected sizeof(char32_t) is 4). Then, found [MSDN]: char, wchar_t, char16_t, char32_t
Notes:
Although this fixed my current problem (still don't know why), will have to give it a shot on the end goal
1 Although I looked over the file, I didn't see any template definitions targeting only the "privileged" types (e.g. I didn't see anything that would differentiate wchar_t, signed char or char32_t from unsigned short for example), so I don't know (yet) why it works for some types but not for others. This is an open topic, whenever I'll get new updates, I will share them
Bottom line:
As empirically discovered, the following types are allowed, when working with char based STL containers:
char
unsigned char
signed char
wchar_t
char16_t
char32_t
unsigned short (/Zc:wchar_t- only )
Final note(s):
I will incorporate anything useful (e.g. comments) in the answer
#EDIT0:
Based on #IgorTandetnik's answer on [MSDN]: Compile error for STL (stream) containers in Visual Studio, although there is still a little bit of fog left on:
unsigned char and signed char
Difference between static and dynamic C++ RTLib
I'm going to accept this as an answer.
The problem occurs because in the templated class std::numpunct, the public variable id is declared with _CRTIMP2_PURE_IMPORT. I haven't chased down the definition of this, but it presumably sets this variable to be imported from the C runtime dll.
The way to fix the problem is to specialize the std::numpunct class for the character type you wish to use, but declare the id variable without _CRTIMP2_PURE_IMPORT.
As the OP refers to a now out of date version of Visual Studio, I won't try and reference specific files or line numbers, as they may change from version to version. I also won't provide a specific specialization that can be used, as this probably depends upon exactly what the OP wants (it may be easy if they wish to just use their locale, or a bit more difficult if they wish to use other/any locale).
Not an answer, but a note to say things are no better three years later. Here's what I get in VS2019 v16.9.4
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include\xlocnum(263,1): error C2491: 'std::numpunct<_Elem>::id': definition of dllimport static data member not allowed
trying to use uint64_t as the character type (Writing a NCurses C++ library, and my version of PDCurses uses 64 bit chtypes...
I'm upgrading from VS2013 to VS2015 and am getting the following warning. I thought VS2015 implemented magic statics so that the local static object should be thread-safe, so what is going on?
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\system_error(698): error C2220: warning treated as error - no 'object' file generated
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\system_error(704): note: see reference to function template instantiation '_Ty &std::_Immortalize<std::_Generic_error_category>(void)' being compiled
with
[
_Ty=std::_Generic_error_category
]
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\system_error(698): warning C4640: '_Static': construction of local static object is not thread-safe
The error is in the system_error header from the VS installation folder. The error is in this function:
template<class _Ty> inline
_Ty& _Immortalize()
{ // return a reference to an object that will live forever
static _Immortalizer<_Ty> _Static;
return (*reinterpret_cast<_Ty *>(&_Static._Storage));
}
That's all the context there is in the error, and I can't see where system_error actually gets included.
Compiler flags are:
/Yu"stdafx.h" /GS /analyze /W3 /wd"4481" /wd"4251" /Zc:wchar_t
/Zi /Gm- /O2 /sdl /Fd"x64\Release\\Release_vc140.pdb" /Zc:inline /fp:precise
/errorReport:prompt /WX /Zc:forScope /Gd /MT /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\MyProj.pch"
Update
Sorry, it seems fixed now. It looks like I was on the v140_xp toolset and wrong TargetPlatformVersion. This one must have slipped through the net when I thought I'd replaced them all. I'm not quite sure why getting those wrong would result in this error though. Anyway, thanks for the help so far.
It looks like its caused by the bogus warning which is turned into an Error, read this connect bug:
https://connect.microsoft.com/VisualStudio/feedback/details/2539759/c4640-warning-cannot-be-disabled
The error C2220 indicates you have enables /WX switch, which tells the compiler to treat all warnings as errors.
you can turn this warning off with:
#pragma warning (disable : 4640)
btw. unrelated, but might be usefull to You. You use _Immortalizer as a name for your class which starts with underscore followed by uppercase latter. This is prohibited by standard: read here: What are the rules about using an underscore in a C++ identifier?.
It's caused by changes in MSBuild's toolset v140_xp. Issue appears when:
project builds with VS2015 Update 2, toolset v140_xp
project configuration is Dynamic Library
project was created with ATL App Wizard, so *.vcxproj contains tag <Keyword>AtlProj</Keyword>
There is workaround: open *.vcxproj file, find tag <Keyword>AtlProj</Keyword> and replace it with <Keyword>Win32Proj</Keyword>. Nothing will be changed while compiling, but warning will disappear.
If you want to know details, navigate to the directory C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\PlatformToolsets\v140_xp, open Toolset.props and find comment <!-- Added /Zc:threadSafeInit- for ATL dll projects and enable the C4640 warnning -->. The line below it enables warning and disables "magic static" feature from C++11.
P.S. Please note that warning isn't useless: 'magic static' uses thread-local storage which suffers from ugly WindowsXP kernel bug: access to TLS from DLL causes crash when application built without TLS support. Any DLL plugins with WinXP support affected by this bug.
I am building in Visual Studio 2013, and if I add unreferenced variables to functions, the compiler does not throw warnings about them. I tried enabling code analysis, per this thread:
Visual Studio 2013 Compiler Warnings not Showing
but that still did not fix my issue. Some additional information:
I have the warning level set to 3 (/W3), am treating warning as errors (/WX), and am in a debug build with no optimization enabled.
My full command line from Project -> Properties -> Configuration Properties -> C/C++ -> Command Line is:
/GS /analyze- /W3 /Zc:wchar_t /ZI /Gm /Od /Fd"generated\debug\intermediate\vc120.pdb" /fp:precise /D "WIN32" /D "GLEW_STATIC" /D "_DEBUG" /D "_WINDOWS" /D "_VC80_UPGRADE=0x0710" /D "_MBCS" /errorReport:prompt /WX /Zc:forScope /RTC1 /Gd /Oy- /MTd /Fa"generated\debug\intermediate\" /EHsc /nologo /Fo"generated\debug\intermediate\" /Fp"generated\debug\intermediate\blahDebug.pch"
I'm iterating on a function that I'm constantly debugging, stepping through the code, etc. -- so I know the code is being run. But if I toss "int blah = 1;" in the function and recompile, no warnings are generated.
Example code:
bool MyClass::doSomething(int someParameter)
{
int blah = 1;
// run the normal function logic here
// 'someParameter' is referenced, but 'blah' never is.
// when i compile, i receive no warning that 'blah' is unreferenced.
return true;
}
In your example code, the statement int blah = 1; both declares the variable and assigns to it. Visual Studio counts this assignment as a "reference" of the variable, thus avoiding the C4101 unreferenced local variable error that you are expecting.
To locate and remove variables which are initialized but never used, you can use a static analysis tool such as Prefast or CppCheck. There is a list of such tools here, though it may be out of date.
Note that the compiler can flag unused parameters, even if they are initialized with a default parameter. If you use warning level 4 via /W4 or /Wall, then an unused parameter will cause a C4100 unreferenced parameter warning. It is a very good idea to always build at /W4 or /Wall, rather than the default /W3.
As Ryan Bemrose outlined, static code analysis tools can be used to detect unused resources from source code.
Take a look at following function:
bool foo(int unusedParameter)
{
int unusedVariable = 1;
return true;
}
It contains two unused resources, an unused parameter and and unused but initialized local variable. Cppcheck can assist you to detect unused local variables, by using the following command:
$ cppcheck --enable=all test.cpp
Checking test.cpp...
[test.cpp:3]: (style) Variable 'unusedVariable' is assigned a value that is never used.
Currently it does not detect unused parameters.
Good morning all. So I'm attempting to disable Warning 4996 in our c++ projects. It seems to be included in the command line as shown below, but upon compiling, still pops up with the C4966 Warning. I've tried changing the warning level to 3, or using /w44996, but neither have worked. Does anyone know why this might be?
/Yu"stdafx.h" /GS- /W4 /wd"4100" /wd"4121" /wd"4201" /wd"4214" /wd"4244" /wd"4996" /Zc:wchar_t /I"C:\Program Files (x86)\MSBuild\..\Common Files\Microsoft Shared\MSEnv" /I"C:\Program Files (x86)\MSBuild\..\Common Files\Designer" /I"D:\Workspaces\MST_Sustaining_Second\Inc" /I"D:\Workspaces\MST_Sustaining_Second\Develop\Shared\Include" /Zi /Gm /Od /Fd"D:\Workspaces\MST_Sustaining_Second\Develop\IDE\GrACE\Debug\vc120.pdb" /fp:precise /D "_USRDLL" /D "ACE_DLL" /D "IQEDITOR_ENABLED" /D "_WINDOWS" /D "_DEBUG" /D "NTDDI_VERSION=NTDDI_WIN7" /D "_WIN32_WINNT=0x0601" /D "WINVER=0x0601" /D "_AFXDLL" /D "WIN32" /D "_SECURE_SCL=0" /D "_WINDLL" /D "_MBCS" /errorReport:prompt /GF- /WX- /Zc:forScope /RTC1 /Gd /Oi /MDd /Fa"D:\Workspaces\MST_Sustaining_Second\Develop\IDE\GrACE\Debug\" /EHs /nologo /Fo"D:\Workspaces\MST_Sustaining_Second\Develop\IDE\GrACE\Debug\" /Fp"D:\Workspaces\MST_Sustaining_Second\Develop\IDE\GrACE\Debug\ace.pch"
EDIT: Typo in description. I do mean Warning 4996, not 4966. 4996 is in the command line as /wd"4996"
For Warning:
warning C4996: 'MBCS_Support_Deprecated_In_MFC': MBCS support in MFC is deprecated and may be removed in a future version of MFC.
It looks like #pragma warning(disable: 4996) will not disable the MBCS deprecation warning due to the
#pragma warning(1: 4996) before the _declspec(deprecated) line in afx.h
For obscure reasons, you must use #define NO_WARN_MBCS_MFC_DEPRECATION to disable this instead.
see afx.h lines 28-33
#ifndef NO_WARN_MBCS_MFC_DEPRECATION
#ifdef _MBCS
// Warn about MBCS support being deprecated: see http://go.microsoft.com/fwlink/p/?LinkId=279048 for more information.
#pragma warning(push)
#pragma warning(1 : 4996)
inline __declspec(deprecated("MBCS support in MFC is deprecated and may be removed in a future version of MFC.")) void MBCS_Support_Deprecated_In_MFC() { }
In order to Pat Brenner (Visual C++ Libraries Development Team) mentioned in his blog ,
we are deprecating MBCS support in MFC for Visual Studio 2013. This
keeps MFC more closely aligned with the Windows SDK itself, because
many of the newest controls and messages are Unicode only
This warning can be eliminated by adding the
NO_WARN_MBCS_MFC_DEPRECATION preprocessor definition to your project
build definitions.
Then do this.
Go to Project Properties-> C\C++ ->Preprocessor->Preprocessor Definition and add NO_WARN_MBCS_MFC_DEPRECATION
I have had a similar issue but it was on some functions from io.h and string.h such as these:
source.cxx(713) : warning C4996: 'stricmp': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _stricmp. See online help for details.
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\string.h(215) : see declaration of 'stricmp'
source.cxx(2416) : warning C4996: 'strdup': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strdup. See online help for details.
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\string.h(207) : see declaration of 'strdup'
source.cxx(2249) : warning C4996: 'isatty': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _isatty. See online help for det
ails.
Due to the need to have the exact same code run be built on other platforms, I had to find a solution without fiddling much in code as this occurred all over the project in a lot of files.
The solution was to add this compiler flag _CRT_NONSTDC_NO_DEPRECATE. This can be done in one of two ways:
Passing -D_CRT_NONSTDC_NO_DEPRECATE if you are using the cl command directly
Or from Visual Studio GUI if you use it for the building process. Add _CRT_NONSTDC_NO_DEPRECATE in Project Properties > C\C++ > Preprocessor > Preprocessor Definition