# "libc++abi" C++ Standard Library Support

libc++abi is a new implementation of low level support for a standard C++ library.

All of the code in libc++abi is dual licensed under the MIT license and the UIUC License (a BSD-like license).

## Features and Goals

- Correctness as defined by the C++11 standard.
- Provide a portable sublayer to ease the porting of libc++
- On Mac OS X, be ABI compatible with the existing low-level support.

## Platform Support

libc++abi is known to work on the following platforms, using clang.

- Darwin

## Current Status

libc++abi is complete. Here is a list of functionality.

## Get it and get involved!

To check out the code, use:

- `svn co http://llvm.org/svn/llvm-project/libcxxabi/trunk libcxxabi`

To build:

- Check out libcxxabi into `llvm/projects`
- `cd llvm`
- `mkdir build && cd build`
- `cmake .. # on linux you may need to prefix with CC=clang CXX=clang++`
- `make`

To do a standalone build:

- Check out the libcxx source tree.
- `cd libcxxabi`
- `mkdir build && cd build`
- `cmake -DLIBCXXABI_LIBCXX_PATH=path/to/libcxx .. # on linux you may need -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++`
- `make`

By default CMake uses `llvm-config` to locate the required LLVM sources. If CMake cannot find `llvm-config` then you must configure CMake using either of the following options.

- `-DLLVM_CONFIG=path/to/llvm-config`
- `-DLLVM_PATH=path/to/llvm-source-root`

To run the tests:

- `make check-libcxxabi`

Note: in a standalone build, the system's libc++ will be used for tests. If the system's libc++ was statically linked against libc++abi (or linked against a different ABI library), this may interfere with test results.

Send discussions to the (clang mailing list).

## Frequently asked questions

Q: Why are the destructors for the standard exception classes defined in libc++abi? They're just empty, can't they be defined inline?

A: The destructors for them live in libc++abi because they are "key" functions. The Itanium ABI describes a "key" function as the first virtual declared. And wherever the key function is defined, that is where the `type_info` gets defined. And in libc++ types are the same type if and only if they have the same `type_info` (as in there must be only one type info per type in the entire application). And on OS X, libstdc++ and libc++ share these exception types. So to be able to throw in one dylib and catch in another (a `std::exception` for example), there must be only one `std::exception type_info` in the entire app. That typeinfo gets laid down beside `~exception()` in libc++abi (for both libstdc++ and libc++).

--Howard Hinnant