| Boost.Locale

- Main Page
- Related Pages
- Modules
- Namespaces
- Classes
- Files
- Examples

Building The library

- Building Boost.Locale
  - Dependencies
  - Building Process
  - Build Options
  - Running Unit Tests
- Binary Compatibility

# Building Boost.Locale

## Dependencies

- ICU library 3.6 or above is strongly recommended
- If no ICU library is given, iconv support is required under POSIX platforms.

## Platform Notes

- If you use Boost.Locale on Windows with MinGW/GCC < 4.5 you'll be able to use static version only. Mingw/GCC prior to 4.5 have no support of dynamic runtime linking.
  Using Boost.Locale DLL's with MinGW gcc also requires dynamic linking with the runtime libraries libstdc++ and libgcc. Some gcc builds use static linking by default so make sure you use correct link options with your compiler when you build your own programs.
- The AIX's iconv misses important character sets that Boost.Locale requires, so you need to either use GNU iconv or link with ICU library.
- If iconv library is not found on Darwin/Mac OS X builds make sure there is no multiple iconv installations and provide -sICONV_PATH build option to point to correct location of iconv library.

## Building Process

Now all you need to do is invoke bjam command:

    ./bjam --with-locale stage

Or on Windows

    .\bjam --with-locale stage

If you are using custom ICU build or you are using Microsoft Windows you need to provide a path to location of ICU library using `-sICU_PATH` option

For example:

- If your icu build is placed at `/opt/icu46` such that the files are placed like
  `/opt/icu46/include/unicode/uversion`.h
  `/opt/icu46/include/unicode/calendar`.h
  ``...
  `/opt/icu46/lib/libicudata`.so
  `/opt/icu46/lib/libicui18n`.so
  ``...
  then you need to provide an option `-sICU_PATH=/opt/icu46`

          ./bjam --with-locale -sICU_PATH=/opt/icu46  stage

- If your icu build is placed at `c:\icu46` such that the files are placed like
  `c:\icu46\include\unicode\uversion.h`
  `c:\icu46\include\unicode\calendar.h`
  `...`
  `c:\icu46\bin\icudt.dll`
  `c:\icu46\bin\icuin.dll`
  `...`
  `c:\icu46\lib\icudt.lib`
  `c:\icu46\lib\icuin.lib`
  `...`
  then you need to provide an option `-sICU_PATH=c:\icu46`

          .\bjam --with-locale -sICU_PATH=c:\icu46  stage

Note
  Don't forget to put both debug and release versions of ICU libraries in this path when using Microsoft Visual Studio so Boost.Build will link correctly debug and release versions of boost_locale library.

# Build Options

Boost.Locale supports following options with values `off` or `on`

- `boost.locale.icu=off` disable build of ICU backend even if ICU library exists
- `boost.locale.iconv=off` or `boost.locale.iconv=on` enable or disable use of iconv library. It is off by default on Windows and Solaris
- `boost.locale.winapi=off` - disable winapi backend, it is on by default on Windows and Cygwin
- `boost.locale.std=off` or `boost.locale.winapi=on` Disable or enable std backends. `std` backend is disabled by default when using Sun Studio.
- `boost.locale.posix=on` or `boost.locale.posix=off` Enable or disable support of POSIX backend, it is on by default on Linux and Mac OS X

Also Boost.Locale supports following options

- `-sICU_PATH=/path/to/location/of/icu` - the location of custom ICU library
- `-sICONV_PATH=/path/to/location/of/iconv` - the location of custom iconv library

For example:

- Build the library on Windows with ICU backend only:

          .\bjam boost.locale.winapi=off boost.locale.std=off -sICU_PATH=c:\icu46 --with-locale stage

- Build the library on Linux with std backend only

          .\bjam boost.locale.posix=off boost.locale.icu=off --with-locale stage

# Running Unit Tests

You can run unit tests by invoking `bjam` with `libs/locale/test` project parameter

    ./bjam libs/locale/test

# Binary Compatibility

Boost.Locale is built with binary compatibility in mind. Switching localization back ends on or off, or using iconv or not, does not affect binary compatibility. So if a dynamic library was built with all possible backends, other dynamic libraries compiled with, for example, only the `std`, `posix` or `winapi` backends would still be binary-compatible with it.

However this definitely has an effect on some features. For example, if you try to use boundary analysis or a calendar facet when the library does not support the icu backend you would get an exception.

- © Copyright 2009-2012 Artyom Beilis, Distributed under the Boost Software License, Version 1.0.