The option -Wl,-rpath,<libcxx-install-prefix>/lib adds a runtime library
search path. Meaning that the systems dynamic linker will look for libc++ in
<libcxx-install-prefix>/lib whenever the program is run. Alternatively the
environment variable LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on OS X) can
be used to change the dynamic linkers search paths after a program is compiled.

Prior to LLVM 9.0, libc++ provides the implementation of the filesystem library
in a separate static library. Users of <filesystem> and <experimental/filesystem>
are required to link -lc++fs. Prior to libc++ 7.0, users of
<experimental/filesystem> were required to link libc++experimental.

Starting with LLVM 9.0, support for <filesystem> is provided in the main
library and nothing special is required to use <filesystem>.

On Linux libc++ can typically be used with only ‘-stdlib=libc++’. However
some libc++ installations require the user manually link libc++abi themselves.
If you are running into linker errors when using libc++ try adding ‘-lc++abi’
to the link line. For example:

GDB does not support pretty-printing of libc++ symbols by default. Unfortunately
libc++ does not provide pretty-printers itself. However there are 3rd
party implementations available and although they are not officially
supported by libc++ they may be useful to users.

This macro is used to enable -Wthread-safety annotations on libc++’s
std::mutex and std::lock_guard. By default these annotations are
disabled and must be manually enabled by the user.

_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS:

This macro is used to disable all visibility annotations inside libc++.
Defining this macro and then building libc++ with hidden visibility gives a
build of libc++ which does not export any symbols, which can be useful when
building statically for inclusion into another library.

_LIBCPP_DISABLE_EXTERN_TEMPLATE:

This macro is used to disable extern template declarations in the libc++
headers. The intended use case is for clients who wish to use the libc++
headers without taking a dependency on the libc++ library itself.

_LIBCPP_ENABLE_TUPLE_IMPLICIT_REDUCED_ARITY_EXTENSION:

This macro is used to re-enable an extension in std::tuple which allowed
it to be implicitly constructed from fewer initializers than contained
elements. Elements without an initializer are default constructed. For example:

Since libc++ 4.0 this extension has been disabled by default. This macro
may be defined to re-enable it in order to support existing code that depends
on the extension. New use of this extension should be discouraged.
See PR 27374 for more information.

Note: The “reduced-arity-initialization” extension is still offered but only
for explicit conversions. Example:

This macro disables the additional diagnostics generated by libc++ using the
diagnose_if attribute. These additional diagnostics include checks for:

Giving set, map, multiset, multimap and their unordered_
counterparts a comparator which is not const callable.

Giving an unordered associative container a hasher that is not const
callable.

_LIBCPP_NO_VCRUNTIME:

Microsoft’s C and C++ headers are fairly entangled, and some of their C++
headers are fairly hard to avoid. In particular, vcruntime_new.h gets pulled
in from a lot of other headers and provides definitions which clash with
libc++ headers, such as nothrow_t (note that nothrow_t is a struct, so
there’s no way for libc++ to provide a compatible definition, since you can’t
have multiple definitions).

By default, libc++ solves this problem by deferring to Microsoft’s vcruntime
headers where needed. However, it may be undesirable to depend on vcruntime
headers, since they may not always be available in cross-compilation setups,
or they may clash with other headers. The _LIBCPP_NO_VCRUNTIME macro
prevents libc++ from depending on vcruntime headers. Consequently, it also
prevents libc++ headers from being interoperable with vcruntime headers (from
the aforementioned clashes), so users of this macro are promising to not
attempt to combine libc++ headers with the problematic vcruntime headers. This
macro also currently prevents certain operator new/operator delete
replacement scenarios from working, e.g. replacing operator new and
expecting a non-replaced operator new[] to call the replaced operator new.

_LIBCPP_ENABLE_NODISCARD:

Allow the library to add [[nodiscard]] attributes to entities not specified
as [[nodiscard]] by the current language dialect. This includes
backporting applications of [[nodiscard]] from newer dialects and
additional extended applications at the discretion of the library. All
additional applications of [[nodiscard]] are disabled by default.
See Extended Applications of [[nodiscard]] for
more information.

This macro disables warnings when using deprecated components. For example,
using std::auto_ptr when compiling in C++11 mode will normally trigger a
warning saying that std::auto_ptr is deprecated. If the macro is defined,
no warning will be emitted. By default, this macro is not defined.

The [[nodiscard]] attribute is intended to help users find bugs where
function return values are ignored when they shouldn’t be. After C++17 the
C++ standard has started to declared such library functions as [[nodiscard]].
However, this application is limited and applies only to dialects after C++17.
Users who want help diagnosing misuses of STL functions may desire a more
liberal application of [[nodiscard]].

For this reason libc++ provides an extension that does just that! The
extension must be enabled by defining _LIBCPP_ENABLE_NODISCARD. The extended
applications of [[nodiscard]] takes two forms:

Backporting [[nodiscard]] to entities declared as such by the
standard in newer dialects, but not in the present one.

Extended applications of [[nodiscard]], at the libraries discretion,
applied to entities never declared as such by the standard.

Users may also opt-out of additional applications [[nodiscard]] using
additional macros.

Applications of the first form, which backport [[nodiscard]] from a newer
dialect may be disabled using macros specific to the dialect it was added. For
example _LIBCPP_DISABLE_NODISCARD_AFTER_CXX17.

Applications of the second form, which are pure extensions, may be disabled
by defining _LIBCPP_DISABLE_NODISCARD_EXT.