I am trying to compile Boost 1.47 for x86 Windows CE using Visual Studio 2008 and STLPort 5.2.1. I can successfully compile for x86 Windows and ARMV4I Windows Mobile 6.5.
When I run bjam, I get this error in most every module:
stlport\ctype.h(42) : fatal error C1083: Cannot open include file: '../1/ctype.h': No such file or directory
That line of code the error refers to in STLPort's ctype.h is:
#include _STLP_NATIVE_C_HEADER(ctype.h)
If I create a new Visual Studio project and add the lines:
#define STR1(x) #x
#define STRINGIZE(x) STR1(x)
#pragma message (STRINGIZE(_STLP_NATIVE_C_HEADER(ctype.h)))
I see: <../X86/ctype.h> as I would expect.
Why is boost replacing "X86" with "1"? It does not have this issue when compiling for ARMV4I Windows Mobile or x86 Windows.
Edit
More information. Something is very deliberately doing a string replace on "X86".
In stlport\stl\config_evc.h I added the pragma messages to this code:
# if !defined (_STLP_NATIVE_INCLUDE_PATH)
# if defined (_X86_)
# if defined (_STLP_WCE_TARGET_PROC_SUBTYPE_EMULATOR)
# define _STLP_NATIVE_INCLUDE_PATH ../Emulator
# else
# define _STLP_NATIVE_INCLUDE_PATH ../X86
# pragma message (STRINGIZE(../abcdefg))
# pragma message (STRINGIZE(../X86))
# pragma message (STRINGIZE(_STLP_NATIVE_INCLUDE_PATH))
# endif
The output is:
../abcdefg
../1
../1
You have X86 macro defined (either by one of the earlier-included headers, or from a command line) and set to 1, so it gets expanded, like macros tend to do. #undef X86 will get rid of it.
Related
I have a VS (C++) project that relies on OpenCV and TBB, so I created property sheets for each library and included them in the project. Everything worked fine and the code compiled.
Yesterday, I have started using vcpkg package manager. I installed OpenCV and TBB via vcpkg and everything seemed to work. I created an empty project, included the headers of both and tested if the new compiled libraries work. After verifying that, I went back to my main project and removed the property sheets, so I can use the libraries from vcpkg. I did not change the code in any way since the last successful compilation.
But when I try to compile the code now I get this error two times (in main.cpp and in a submodule)
tbb\critical_section.h(53): error C3861: 'InitializeCriticalSectionEx': identifier not found
Does anybody know what is going on here or why this error occurs?
Update
I found the error myself. I'm adding the poco-libraries tag, because it's actually a conflict between TBB and Poco.
I found the source of the problem and it has actually nothing to do with TBB but with the Poco library.
Consider the minimum example:
#include <Poco/Poco.h>
#include <tbb/tbb.h>
void main()
{
}
This will throw an compiler error.
Tracing down the path
When including tbb.h, critical_section.h is included in line 51 of tbb.h. However, ciritcal_section.hpp includes machine/winwdows_api.h which looks like this (unnecessary stuff is cut out):
tbb/machine/winwdows_api.h:
#if _WIN32 || _WIN64
#include <windows.h>
#if _WIN32_WINNT < 0x0600
#define InitializeCriticalSectionEx inlineInitializeCriticalSectionEx
inline BOOL WINAPI inlineInitializeCriticalSectionEx( LPCRITICAL_SECTION lpCriticalSection, DWORD dwSpinCount, DWORD )
{
return InitializeCriticalSectionAndSpinCount( lpCriticalSection, dwSpinCount );
}
#endif
As you can see, windows.h is included before the check of the _WIN32_WINNT macro. This macro is defined in sdkddkver.h (which is included in windows.h), iff it's not already defined (in my case it's set to Win10):
sdkddkver.h:
#if !defined(_WIN32_WINNT) && !defined(_CHICAGO_)
#define _WIN32_WINNT 0x0A00
#endif
In windows.h, the _WIN32_WINNT macro controls which version of the windows header files are actually included. If _WIN32_WINNT is set to an earlier version than Windows Vista, the function InitializeCriticalSectionEx is not defined.
This issue is catched by machine/winwdows_api.h (as you can see in the code block of that file) by simply defining a macro InitializeCriticalSectionEx that calls an appropriate alternative function.
So far so good.
The problem
The root of all evil lies in Poco/UnWindows.h of the Poco library. When including a poco header, at some point UnWindows.h will be included.
Poco/UnWindows.h (shortened):
#if defined(_WIN32_WINNT)
#if (_WIN32_WINNT < 0x0501)
#error Unsupported Windows version.
#endif
#elif defined(NTDDI_VERSION)
#if (NTDDI_VERSION < 0x05010100)
#error Unsupported Windows version.
#endif
#elif !defined(_WIN32_WINNT)
#define _WIN32_WINNT 0x0501
#define NTDDI_VERSION 0x05010100
#endif
#endif
#include <windows.h>
The preprocessor checks, if _WIN32_WINNT is already defined, and if not, sets it to 0x0501 which is Windows XP. After that, windows.h is included. In the previous chapter I mentioned that _WIN32_WINNT controls which version of the windows header files are actually included.
Now imagine, the very first include in our project is a header from Poco. This means, that _WIN32_WINNT will be set to Windows XP and windows.h will include the windows headers of Windows XP (which imo is already a bad sign).
But don't worry, it gets worse.
If we trace the include hierarchy one level up, we reach Poco/Platform_WIN32.h.
Poco/Platform_WIN32.h (shortened):
#include "Poco/UnWindows.h"
...
#if defined (_WIN32_WINNT_WINBLUE)
#ifdef _WIN32_WINNT
#undef _WIN32_WINNT
#endif
#define _WIN32_WINNT _WIN32_WINNT_WINBLUE
...
Funny, isn't it? First, it includes UnWindows.h, which sets _WIN32_WINNT and causes Windows XP headers to be included, and next it redefines _WIN32_WINNT to be Windows 8.1. I have no clue why it does that, maybe there is a good reason, idk.
If we now look at the minimum example at the very top we see that Poco is included before TBB. What now happens is:
Include Poco headers
Set _WIN32_WINNT to Windows XP
Include windows headers (Windows XP version, because of 2)
Reset _WIN32_WINNT to Windows 8.1
Include TBB headers (windows headers are already included, so TBB doesn't need to include them again in tbb/windows_api.h)
TBB checks the windows version via _WIN32_WINNT and recognizes Windows 8.1 (as set by Poco)
TBB thinks InitializeCriticalSectionEx is defined, because the Windows version is 8.1 (or is it? Poco says: get rekt) and InitializeCriticalSectionEx is defined since Windows Vista.
Unfortunately Poco ensured that the Windows XP headers are loaded, so compiler says: no.
The solution
Either include windows.h yourself beforehand, or set _WIN32_WINNT yourself beforehand:
#define _WIN32_WINNT 0x0A00 // either this
#include <Windows.h> // or this
#include <Poco/Poco.h>
#include <tbb/tbb.h>
void main()
{
}
Maybe someone of the Poco contributors can clarify some things here. The Poco version is 1.8.1-1 built with x64 (via vcpkg).
Update
Poco is on the issue. Updates can be found here.
I'm trying to build gnuplot with Visual Studio 2015. To this end I run the Makefile located in the config\msvc :
Start the Microsoft Visual C++ command shell
change to the config\msvc
Run nmake -f Makefile
but I obtain the following fatal error :
c:\.......\gnuplot\src\gnuplot-5.0.1\gnuplot-5.0.1\src\syscfg.h(377): error C2632: 'char' ne peut pas être suivi de 'bool'
Is it the correct way to build the 5.0.1 version of gnuplot for windows ? Have you already seen this error ?
The problem is with bool type: Microsoft Visual Studio (since version 2013) package includes a library with bool as a type. Somewhy, HAVE_STDBOOL_H is not defined on your system. The issue has already been faced when compiling other software.
I can suggest you two possibilities:
1) write #define HAVE_STDBOOL_H in gnuplot-5.0.1\src\syscfg.h just above line 370
2) Open Makefile, add /DHAVE_STDBOOL_H to CFLAGS, or, even to CBASEFLAGS.
gnuplot-5.0.1\src\syscfg.h (370-384):
#if HAVE_STDBOOL_H
# include <stdbool.h>
#else
# if ! HAVE__BOOL
# ifdef __cplusplus
typedef bool _Bool;
# else
typedef unsigned char _Bool;
# endif
# endif
# define bool _Bool
# define false 0
# define true 1
# define __bool_true_false_are_defined 1
#endif
The way you build it is believed to be correct, it agrees with the original guide provided in Makefile:
Start the Microsoft Visual C++ command shell (e.g. via link installed
setup)
Change to the gnuplot\config\msvc directory
Edit the Makefile to match your setup. (If you don't have the optional libraries, you will probably have to disable some parts.)
Now run:
nmake
I have just started a project c++ with Panda3D. ( Visual Studio 2010 )
With a simple HelloWorld, I add paths etc. No compile error except :
an error just appeared :
error LNK1104: cannot open file 'python27_d.lib'
And I have no idea how to fix it.
Plz help !
Thanks !
There's a few things you can do.
1) just build in release mode (not a good solution, since you can't debug too well this way)
2) add another build configuration based on "Release" but with debug symbols and without the _DEBUG preprocessor definition (can mess up some libraries)
3) find or build a Python 2.7 version with debug and release libraries build in Visual Studio 2010
4) just change this one section in the pyconfig.h where it actually links to the *.lib file to just use the python27.lib for both configurations.
/* For an MSVC DLL, we can nominate the .lib files used by extensions */
#ifdef MS_COREDLL
# ifndef Py_BUILD_CORE /* not building the core - must be an ext */
# if defined(_MSC_VER)
/* So MSVC users need not specify the .lib file in
their Makefile (other compilers are generally
taken care of by distutils.) */
# ifdef _DEBUG
# //-----------------------change the next line-------------//
# pragma comment(lib,"python27_d.lib")
# else
# pragma comment(lib,"python27.lib")
# endif /* _DEBUG */
# endif /* _MSC_VER */
# endif /* Py_BUILD_CORE */
#endif /* MS_COREDLL */
1) 2) and 4) are hacky solutions, so I'd suggest you try to use 3).
EDIT 2: Ok so I changed to Orwell DevC++ which contains the "winnt.h" that contains #define KEY_WOW64_64KEY 0x0100 but it still is not working. (Refer to EDIT 1:)
EDIT 1: I looked into the "winnt.h" which came along the CodeBlock and DevC++ and the DevC++'s is missing the following lines:
#if (_WIN32_WINNT >= 0x0502)
#define KEY_WOW64_64KEY 0x0100
#define KEY_WOW64_32KEY 0x0200
#endif
And putting the above code in the wint.h of DevC++ doesn't work.
Original Post:
I have a 32bit application (developing in DevC++ and Windows 7 64bit) which reads a 64bit app's registry as one of its task, so I am trying to use "KEY_WOW64_64KEY" flag in RegOpenKeyEx, and found few posts regarding how to use it with _WIN32_WINNT : this and this
It worked like charm when I used it in a CodeBlock Project(a test project) but the same code is not working with DevC++, I can't port it to codeblock now since codeblock presents other problems.
How do I make it work with DevC++ ?
Thanks
It defines the version of the windows header files to use. It must be declared before you #include <Windows.h>.
There are a few other similar variables you should probably set if you're going to modify it:
MSDN Using Windows Headers
_WIN32_WINNT is a preprocessor token, which is replaced by (0x0601) wherever _WIN32_WINNT is used. The preprocessor just scans the whole file and replaces _WIN32_WINNT with (0x0601) everywhere it is found.
Chances are, there could be ifdef preprocessor guards that will enable/disable a preprocessor constant. Like:
#ifdef _WIN32_WINNT
#define KEY32 32
#endif
There, KEY32 will only be defined IF _WIN32_WINNT is defined.
It already works with DevC++.
I am trying to migrate existing c++ 32 code to 64 code on windows7 with visual studio 2010.i never did 64bit compilation before. with the help of internet references i did the setup for 64 bit compilation. like VS2010 with 64 bit compiler etc and other configuration changes.
In the preprocessor i removed WIN32 and added WIN64. i have some other pre-processors like OS_WIN_32 and some other which are specific in my code.
In the code wherever WIN32 was getting used i added extra condition as || WIN64 this is just to ensure that application should get compiled with win32 as well as win64.
When i am trying to compile the code i am getting the compilation error saying
fatal error C1189: #error : Only one of the WIN32 and WIN64 symbols should be defined
this error is coming from the local code where we have a check whether both WIN32 and WIN64 are defined. that code is as shown below.
#if defined WIN32 && defined WIN64
# error Only one of the WIN32 and WIN64 symbols should be defined
#endif
in VS2010 if macros are not enabled then the code inside the macro gets greyed out. in my code also the above error is greyed out. but still i am getting that error.
The code where i added WIN64 is including windows.h. for reference givine it below.
#if defined WIN32 || defined WIN64
#include <windows.h>
#include <process.h>
#endif
So my question is why i am getting this error? shouldnt we add windows.h for 64bit compilation.? i tried by commenting this inclusion but i am getting other errors wrt HANDLE which are used in the code.
If i go to WIN32 definition VS2010 is pointing to a definition in windef.h file. This file is present in Microsoft SDKs\windows\v7.0A\include folder i.e. not my local code.
for referance that definition is given below.
#ifndef WIN32
#define WIN32
#endif
So i want to know why compiler is getting both pre-processors WIN32 and WIN64.
Thanks in advance for your help.
You shouldn't define either yourself. The macro's that should be used to check this are
_WIN32 // always defined for Windows apps
_WIN64 // only defined for x64 compilation
These are defined by the compiler (see here).
Often, the IDE adds the unprefixed macros to the commandline to not let legacy projects which use the non-documented unprefixed versions fail to build. The fact that they work is not a reason to use them, when documented alternatives are present.
It boils down to this:
#ifdef _WIN32
// We're on Windows, yay!
#ifdef _WIN64
// We're on x64! Yay!
#else // _WIN64
// We're on x86 (or perhaps IA64, but that one doesn't matter anymore). Yay!
#endif // _WIN64
#else // _WIN32
// We're not on Windows, maybe WindowsCE or WindowsPhone stuff, otherwise some other platform
#endif