Boost C++ Libraries: Ticket #633: [config] evc4 port

John Maddock — Wed, 17 May 2006 09:51:59 GMT

Logged In: YES
user_id=14804
I notice that the patches are arm-specific, surely VC8 can
be used to target other processors?
John.

vividos — Wed, 17 May 2006 13:22:34 GMT

Logged In: YES
user_id=124874
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.

Mateusz Loskot — Tue, 30 May 2006 02:52:38 GMT

Logged In: YES
user_id=736047
Hi,
Michael:
Thanks for your effor to make Boost more Windows
CE-friendly. Some time ago, I also started to use Boost with
eVC++/VC++8.
John:
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:
http://www.smartphonedn.com/qa/checkos.html
Here is a table that explains how to map devie arch from
eVC++ 3/4 to VC++ 8.0:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/migrating_evc_vs2005.asp
Also, biuld system should define appropriate symbols:
-D _ARM_ -D ARM -D _arm_
-D _MIPS_ -D MIPS -D _mips_
etc.
Cheers

John Maddock — Sat, 03 Jun 2006 11:57:24 GMT

Logged In: YES
user_id=14804
Some more comments and questions:
Shouldn't
#ifndef _CPPUNWIND
#  error C++ Exception handling is not switched on, which is
neccessary for Boost! Please add /GX to your compiler options.
#endif
be:
#ifndef _CPPUNWIND
#  define BOOST_NO_EXCEPTIONS
#endif
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.
John.

msclrhd — Sat, 03 Jun 2006 20:57:54 GMT

Logged In: YES
user_id=761714
I am working on providing support for WinCE platforms by
extending the BBv2 msvc.jam toolset. See
http://www.reece-dunn.co.uk 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

John Maddock — Sun, 04 Jun 2006 08:54:01 GMT

Logged In: YES
user_id=14804
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.
John.

msclrhd — Sun, 11 Jun 2006 17:57:15 GMT

Logged In: YES
user_id=761714
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:
WINCE, _WIN32_WCE and UNDER_CE.
[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"
+#else
+#  error Unrecognised Windows platform.
+#endif
- Reece

vividos — Mon, 12 Jun 2006 15:30:42 GMT

Logged In: YES
user_id=124874
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
_WIN32_WCE.
[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
BOOST_NO_EXCEPTIONS when _CPPUNWIND isn't defined.

vividos — Mon, 30 Oct 2006 09:49:57 GMT

Logged In: YES
user_id=124874
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.

component changed; severity set

Daryle Walker — Fri, 03 Aug 2007 12:07:40 GMT

component None → config
severity → Problem

status, description changed

John Maddock — Thu, 01 Nov 2007 17:08:28 GMT

status assigned → closed
description modified (diff)

I'm closing this issue down because we now (finally!) have someone running the regression tests on the Windows Mobile 5 Platform, and making the appropriate patches to get Boost working there.