Opened 16 years ago
Closed 15 years ago
#633 closed Patches (None)
[config] evc4 port
Reported by: | vividos | Owned by: | John Maddock |
---|---|---|---|
Milestone: | Component: | config | |
Version: | None | Severity: | Problem |
Keywords: | Cc: |
Description (last modified by )
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.
Change History (11)
comment:2 by , 16 years ago
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:3 by , 16 years ago
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
comment:4 by , 16 years ago
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:5 by , 16 years ago
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:6 by , 16 years ago
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:7 by , 16 years ago
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:8 by , 16 years ago
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:9 by , 16 years ago
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:10 by , 15 years ago
Component: | None → config |
---|---|
Severity: | → Problem |
comment:11 by , 15 years ago
Description: | modified (diff) |
---|---|
Status: | assigned → closed |
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.
Note:
See TracTickets
for help on using tickets.