Partial Port of Boost Available for BlackBerry 10

Author: Clifford Hung
Date: May 21, 2012

Selected parts of the Boost C++ libraries (version 1.48.0) have been ported to run on BB 10. The following libraries have been ported using the default Dinkum C++ libraries and pass Boost’s test suite.

  • Boost.Date_Time
  • Boost.Filesystem
  • Boost.Program_options
  • Boost.Random
  • Boost.Regex
  • Boost.System
  • Boost.Thread

The headers listed here have also been ported and pass Boost’s tests.

These headers and libraries also work with the GNU C++ libraries although there a few unresolved test failures involving Boost.Date_Time and Boost.Regex. See the Known issues with tests section for details.

Since future changes to port the rest of Boost for Dinkum and GNU libraries may not be compatible and to accommodate differences in the build and test scripts, there are branches for each port (1_48_0-dinkum and 1_48_0-gnu).

Building Boost

Both Dinkum and GNU ports can be built using Boost’s own build system which uses bjam and Jamfiles. For the Dinkum port, a second (and recommended) approach is to use the recursive makefile (rmake) setup. The rmake build is recommended to build the Dinkum port as the script to build the test suite will require the rmake build of the libraries. The two build setups use slightly different flags so the output libraries will not be exactly the same.

Ensure that you source the BlackBerry Native SDK environment variables. From your NDK installation directory (e.g. ~/bbndk-2.0.1) run . ./bbndk-env.sh.

Building with bjam

Change to the rim-build directory. Run the build.sh script using this command:

    ./build.sh install

This will build the libraries in subdirectories of bin.v2 as well as copy them to a staging directory (under rim-build/boost-stage).

For the GNU port, all the libraries are compiled, not just the ported ones. The Boost.Python library can be enabled by setting the PYTHON_SRC_DIR variable in build.sh to the Python source location.

Use ./build.sh clean to clean the build.

Building with rmake (Dinkum port only)

From the top-level directory, run make. This will create libraries under each library’s build directory, for example, the filesystem library is built under libs/filesystem/build for ARM and X86. For building the tests, the libraries need to be copied to a staging directory using the following command:

    make install INSTALL_ROOT_nto=<Path to boost repo>/rim-build/boost-stage

Partial builds can be accomplished using the LIST tag found in the makefiles. For example, you could build debug ARM libraries by running this command:

    make CPULIST=arm VARIANTLIST=g

Use make clean to clean the build.

Testing Boost

Under the rim-test directory are scripts to build and run Boost’s test suite. The build-tests.sh script will invoke bjam on each test directory read from the test.list file. You can choose to skip some tests by commenting them out with a ”#”. The build script will build and attempt to run the tests. The test failures can be ignored since they aren’t being run on a BB 10 device.

The test binaries can either be copied over to a device in development mode (using scp) or the top-level boost directory can be NFS-mounted on the device. It will be easier to recompile and rerun tests with the latter setup but some of the filesystem tests may fail due to issues with NFS.

NFS setup for Ubuntu Linux and PlayBook over USB

On your Linux machine, obtain the packages to install the NFS server:

    sudo apt-get install nfs-kernel-server nfs-common portmap

Edit the NFS exports file as follows:

    sudo vi /etc/exports

Add the following line:

    <Path to boost repo> 169.254.0.1(rw,all_squash,async,insecure,no_subtree_check,anonuid=<UID>,anongid=<GID>

Make the NFS server reread the configuration:

    sudo service nfs-kernel-server reload

On the PlayBook, issue the following command to mount the NFS-exported directory:

    fs-nfs3 169.254.0.2:<Path to boost repo on server> /accounts/devuser/boost

Running the tests

Change to /accounts/devuser/boost/rim-test. To run the test script capturing both stderr and stdout, use the following command:

    ./run-tests.sh 2> run.err > run.out &

You may then use the tail command to observe the progress of the tests, e.g. tail -f run.out.

Known issues with tests

• Some of the filesystem tests may fail when run from an NFS mount (e.g. bin.v2/libs/filesystem/test/v3_operations_test.test/qcc/debug/architecture-arm/target-os-qnxnto/threading-multi/v3_operations_test)

bin.v2/libs/date_time/test/teststreams.test/qcc/debug/architecture-arm/target-os-qnxnto/threading-multi/teststreams (see stdout, stderr; the test failure involves type std::wistringstream)

bin.v2/libs/regex/test/regex_regress_recursive.test/qcc/debug/architecture-arm/target-os-qnxnto/threading-multi/regex_regress_recursive (see stdout, stderr). In the test case “test_recursion”, there are many failures related to expected regex matches not being found; see this example.

bin.v2/libs/regex/test/regex_regress_threaded.test/qcc/debug/architecture-arm/target-os-qnxnto/threading-multi/regex_regress_threaded (see stdout, stderr). Failures are similar to regex_regress_recursive.

bin.v2/libs/regex/test/regex_regress.test/qcc/debug/architecture-arm/target-os-qnxnto/threading-multi/regex_regress (see stdout, stderr). Failures are similar to regex_regress_recursive.