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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With