编译用于Windows CE的Boost 1.47

Question

There is actually a bit of information out there about people trying to build the Boost libraries for Windows CE, but no one has reported success or even given the steps required to do so. With the two latest releases (1.46 and 1.47) the release notes have mentioned that one of their test compilers was "Visual C++, Windows Mobile 5, with STLport: 9.0," which seems to imply that success has been achieved (as a side note the compiler given is interesting since the latest STLPort I've been able to download is 5.2.1. Am I missing something?).

The posts I've found seem to revolve around the file contained here: http://www.boost.org/development/tests/trunk/VeecoFTC.html . The thing is, I honestly don't know how to use it. I was able to build STLPort for Windows CE, but following the Boost Getting Started guide ( http://www.boost.org/doc/libs/1_47_0/more/getting_started/windows.html ) I get stuck at the Boost.Build stage. Do I need to configure at this point to compile for CE? I just don't know what steps to take and would appreciate some guidance.

These are the steps I have followed so far:

1. Compile STLPort for Windows CE (documentation was pretty decent, this didn't prove too difficult).
2. Install Boost.Build according to Getting Started Guide. I'm a little shaky on this step, since the bootstrap.bat file seems to be specific to "ntx86" and "ntx86_64." Have I already screwed up?

At this point, assuming I've done things correctly, I need to run b2 with something like

b2 --build-dir=build-directory toolset=toolset-name --build-type=complete stage

I assume my build directory is the prefix I used for Boost.Build, the build type and stage will remain as given, but I don't know what toolset name to use. The VeecoFTC file has multiple entries for msvc and stlport. I removed the two entries that DIDN'T relate to "wm5," but when I compile with the following command

b2 --build-dir=C:\boost-build toolset=msvc --build-type=complete stage

I get a bunch of errors like:

compile-c-c++ C:\boost-build\boost\bin.v2\libs\regex\build\msvc-9.0~wm5~stlport5.2\debug\threading-multi\has_icu_test.obj
The system cannot find the path specified.

Indeed, that file does not exist, but has_icu_test.obj.rsp exists there. Am I missing something? Am I even on the right track?

UPDATE:

Since I can't get Boost.Build to work and am getting no love on the Boost.Build mailing list, I've moved on to trying the CMake build system for Boost: http://gitorious.org/boost/cmake . I'm using this in conjunction with CEgcc (I'm much more familiar with Linux than Windows) and I'm running into the following error:

boost/config/requires_threads.hpp:47:5: error: #error "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)"

-mthreads is part of the C and CXX flags-- the problem is that BOOST_PLATFORM_CONFIG is not defined by boost/config/select_platform_config.hpp. What should this be defined to for Windows CE? I figured it should be boost/config/platform/win32.hpp (which would then define BOOST_HAS_WINTHREADS, which would solve the above error). How can the release notes claim this works when select_platform_config.hpp doesn't seem to handle Windows CE cases? If BOOST_PLATFORM_CONFIG does indeed need to be boost/config/platform/win32.hpp, then I need to define either _WIN32, WIN32 , or WIN32. My first reaction is that none of these should be used for compiling for CE. Also, the VeecoFTC file doesn't contain any of these. How does IT work?

Answer 1

You don't actually have to use boost build to build boost. I built part of boost using an SCons script for a project where I needed more control over the build options. It worked quite well. It went something like this:

import os

env = Environment()

boost_source = os.environ.get('BOOST_SOURCE', None)
if not boost_source:
    raise Exception, 'BOOST_SOURCE not set'

env.Append(CPPPATH = [boost_source])

if env['PLATFORM'] == 'win32':
    env.Append(CPPDEFINES = ['BOOST_ALL_NO_LIB'])


VariantDir('build', boost_source + '/libs')

import glob
import re

for lib in ['iostreams', 'filesystem', 'system', 'regex', 'thread',
            'serialization']:
    src = []
    path = boost_source + '/libs/%s/src' % lib

    if lib == 'thread':
        if env['PLATFORM'] == 'win32':
            src.append(path + '/tss_null.cpp')
            path += '/win32'
            env.Append(CPPDEFINES = ['BOOST_HAS_WINTHREADS',
                                     'BOOST_THREAD_BUILD_LIB'])
        else: path += '/pthread'

    src += glob.glob(path + '/*.cpp')

    src = map(lambda x: re.sub(re.escape(boost_source + '/libs'), 'build', x),
              src)

    libname = 'boost_%s' % lib
    if env['PLATFORM'] == 'win32': libname = 'lib' + libname
    lib = env.Library('lib/' + libname, src)

Clean(lib, 'build')
Clean(lib, 'lib')

This SCons script just searches for the source files in the listed boost modules and compiles with the default compiler. I pass in the path to the boost source directory via the BOOST_SOURCE environment variable.

This could work for Windows CE as it would give you more control over the build process. You could also do something similar with make or nmake.

The moral of the story is that building boost with out using bjam/BoostBuild is not that hard.

Answer 2

I've compile with success Boost.Thread, Boost.Regex, Boost.System, Boost.Chrono and Boost.Atomic for Windows CE 6.0 on an x86 Platform.

The major work was to make WinCE more ANSI C compiliant. I've changed a bit STLPort and integrated with missing C function. Then I built boost with STLPort.

Look at the following link the I posted:

http://stackoverflow.com/questions/15906901/build-boost-c-wince

http://stackoverflow.com/questions/16016637/boost-c-and-windows-ce-6-0

http://stackoverflow.com/questions/15959877/windows-ce-6-0-and-runtime-link-to-debug-dll-mdd

http://stackoverflow.com/questions/11079337/wince-5-0-using-stlport-void-operator-newsize-t-void-already-has-a-body/15814730#15814730

Answer 3

This is the sort of error you would see if the msvc tool-set configuration has an incorrect path to where the tool-set is installed. I've seen such errors on 64-bit windows machines, where tools assume the compiler is installed in "C:\\Program Files" but it is actually in "C:\\Program Files (x86)"

Check the tool-set configuration and make sure it matches the location of where the SDK is installed.