Boost logo

Boost :

From: (noreply_at_[hidden])
Date: 2006-10-30 04:49:57

Patches item #1489359, was opened at 2006-05-16 09:38
Message generated for change (Comment added) made by vividos
You can respond by visiting:

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Fink (vividos)
Assigned to: John Maddock (johnmaddock)
Summary: [config] evc4 port

Initial Comment:
This patch is a port for evc3/4 targeting Windows CE.
Reason for the changes in auto_link.hpp: STLport with
evc4 cannot be compiled in _STLP_DEBUG mode; the
compiler issues wrong ARM code and _STLP_DEBUG mode
cannot be used with evc4 ARM. I also introduced a new
file wince.hpp in boost/config/platform/, since the
defines in the _WIN32_WCE part got too big.


>Comment By: Michael Fink (vividos)
Date: 2006-10-30 10:49

Logged In: YES

I updated the patch for the current 1.34 CVS branch. I
removed the wince.hpp again, since it mostly defined
standard C library functions that are missing on evc4, and I
think that sould be done with some other libs. I removed the
defining of BOOST_NO_EXCEPTIONS again when _CPPUNWIND is not
enabled, since that's already done in visualc.hpp. I also
removed the define for TLS_OUT_OF_INDEXES that's needed for
evc4 in Boost.Threads, since that should probably go there.


Comment By: Michael Fink (vividos)
Date: 2006-06-12 17:30

Logged In: YES

In response to user msclrhd:

[1] It's 400, check STLport's evc config if unsure.

[2] Reporting a warning when _WIN32_WCE < 400 is sensible,
since evc3 probably cannot use most of Boost. Checking if
_WIN32_WCE is defined at all is not sensible, since then
wince.hpp wouldn't be included at all. See win32.hpp.

[3, 4, 5, 6] Well, I'm not responsible for the user to mess
up his defines, so it's his problem. The only define used is

[7] There are several other libraries that try to provide
missing C APIs. Do you have a suggestion how to solve this?

[8] I moved it out of win32.hpp since it got too large.
Check out the patched win32.hpp to see how the file relates
to wince.hpp

[9] Since the patch is only meant to be a port for evc4, I
didn't do this change.

I changed the patch so that it doesn't redefine _WIN32_WINNT
anymore. It seems that wasn't needed. I also now define


Comment By: Reece H Dunn (msclrhd)
Date: 2006-06-11 19:57

Logged In: YES

John, I agree with your comments about _CPPUNWIND and
_WIN32_WINNT. I thought that _WIN32_WINNT should *not* be
defined. Here are some comments:

[1] The check for WinCE uses _WIN32_WCE >= 400 -- shouldn't
this be _WIN32_WCE >= 0x0400?

[2] Report a warning if _WIN32_WCE < 400 or not defined!

[3] Issue an error/warning if any of the following are
defined: WIN32, WIN64, _WIN32_WINNT, _WIN32_WINDOWS and WINVER.

[4] Issue an error if any of the following are not defined:

[5] Ensure that WIN32_PLATFORM_PSPC (PocketPC) and
WIN32_PLATFORM_WFSP (SmartPhone) are not defined together.

[6] Ensure that _WIN32_WCE and UNDER_CE have compatible,
sensible values.

[7] I don't like the idea of always providing the C API
directly -- what if some other project (like ATL/WTL)
defines these!

[8] This should be merged with win32.hpp -- that already has
a _WIN32_WCE section and defines other things related to
Windows not present here.

[9] Do we want to distinguish between Win32/64/CE in
win32.hpp. If so, I suggest having:

-#define BOOST_PLATFORM "Win32"
+#if defined(WIN32)
+# define BOOST_PLATFORM "Win32"
+#elif defined(WIN64)
+# define BOOST_PLATFORM "Win64"
+#elif defined(WINCE)
+# define BOOST_PLATFORM "WinCE"
+# error Unrecognised Windows platform.

- Reece


Comment By: John Maddock (johnmaddock)
Date: 2006-06-04 10:54

Logged In: YES

Thanks Reece that would be very useful, if you can put
together a better config setup than the one provided here
that would be great: it still doesn't look right to me, but
I don't have embedded VC8 to test with so I can't really tell.



Comment By: Reece H Dunn (msclrhd)
Date: 2006-06-03 22:57

Logged In: YES

I am working on providing support for WinCE platforms by
extending the BBv2 msvc.jam toolset. See for the updates.

I am adding the -DARM, -DWINCE, etc. as required by the
platforms as well as adding -machine:ARM4, etc. to the
linker. It is still very much a work in progress, so help
getting this working would be very much appreciated.

- Reece


Comment By: John Maddock (johnmaddock)
Date: 2006-06-03 13:57

Logged In: YES

Some more comments and questions:


#ifndef _CPPUNWIND
# error C++ Exception handling is not switched on, which is
neccessary for Boost! Please add /GX to your compiler options.


#ifndef _CPPUNWIND

I'm also concerned about hard coding the value of
_WIN32_WINNT: this is very bad manners at the very least!

Finally, shouldn't those C functions be defined in namespace
std? I presume that the header needs to include <cstring>
as well otherwise I don't see how it can possibly compile.



Comment By: Mateusz Loskot (mloskot)
Date: 2006-05-30 04:52

Logged In: YES


Thanks for your effor to make Boost more Windows
CE-friendly. Some time ago, I also started to use Boost with

VC++ 8.0 brings the whole set of compilers for Winodows CE
platform: clarm.exe, clmips.exe, etc.
Here is a list with preprocessor macros to check target arch:

Here is a table that explains how to map devie arch from
eVC++ 3/4 to VC++ 8.0:

Also, biuld system should define appropriate symbols:
-D _ARM_ -D ARM -D _arm_
-D _MIPS_ -D MIPS -D _mips_



Comment By: Michael Fink (vividos)
Date: 2006-05-17 15:22

Logged In: YES

The only change I made is to rename "evc8" to "msvc8-arm",
but since I don't know exactly how to differentiate
processors in msvc8 I simply put "msvc8-arm". A possible
msvc8 porter has to decide that.

I updated the patch since I found another issue: there's no
static C runtime for Windows CE, so autolinking always
chooses "-gdp" now. Please disregard the first patch.


Comment By: John Maddock (johnmaddock)
Date: 2006-05-17 11:51

Logged In: YES

I notice that the patches are arm-specific, surely VC8 can
be used to target other processors?



You can respond by visiting:

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Boost-bugs mailing list

Boost list run by bdawes at, gregod at, cpdaniel at, john at