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: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489359&group_id=7586 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

Message: 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. ---------------------------------------------------------------------- Comment By: Michael Fink (vividos) Date: 2006-06-12 17:30 Message: 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. ---------------------------------------------------------------------- Comment By: Reece H Dunn (msclrhd) Date: 2006-06-11 19:57 Message: 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 ---------------------------------------------------------------------- Comment By: John Maddock (johnmaddock) Date: 2006-06-04 10:54 Message: 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. ---------------------------------------------------------------------- Comment By: Reece H Dunn (msclrhd) Date: 2006-06-03 22:57 Message: 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 ---------------------------------------------------------------------- Comment By: John Maddock (johnmaddock) Date: 2006-06-03 13:57 Message: 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. ---------------------------------------------------------------------- Comment By: Mateusz Loskot (mloskot) Date: 2006-05-30 04:52 Message: 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/ht... Also, biuld system should define appropriate symbols: -D _ARM_ -D ARM -D _arm_ -D _MIPS_ -D MIPS -D _mips_ etc. Cheers ---------------------------------------------------------------------- Comment By: Michael Fink (vividos) Date: 2006-05-17 15:22 Message: 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. ---------------------------------------------------------------------- Comment By: John Maddock (johnmaddock) Date: 2006-05-17 11:51 Message: Logged In: YES user_id=14804 I notice that the patches are arm-specific, surely VC8 can be used to target other processors? John. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489359&group_id=7586 ------------------------------------------------------------------------- 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 http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs