Commit Graph

6 Commits

Author SHA1 Message Date
Eric Fiselier
74c9857af9 Expect DLL builds on Windows by default and require a custom __config for static
builds.

On Windows the __declspec(dllimport) and __declspec(dllexport) attributes
require linking to a DLL, not a static library. Previously these annotations
were disabled by default unless _LIBCPP_DLL was defined. However the DLL
configuration is probably the more common one, so it should be supported by
default.

This patch enables import/export attributes by default and adds a
_LIBCPP_DISABLE_DLL_IMPORT_EXPORT macro which can be used to disable this
behavior. If libc++ is built as a static library on Windows then a custom __config
header will be generated that predefines this macro.

This patch is based off work by Shoaib Meenai.


git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@282449 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-26 22:19:41 +00:00
Asiri Rathnayake
040945b81f [libcxx] Introduce an externally-threaded libc++ variant.
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:

- Building libc++ against a thread library other than pthreads.

- Building libc++ with an "external" thread API, allowing a separate library to
  provide the implementation of that API.

The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.

For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.

Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.

When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).

Differential revision: https://reviews.llvm.org/D21968

Reviewers: bcraig, compnerd, EricWF, mclow.lists

git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@281179 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-11 21:46:40 +00:00
Ben Craig
5163e46afb [libcxx] Allow explicit pthread opt-in
The existing pthread detection code in __config is pretty good for
common operating systems. It doesn't allow cmake-time choices to be
made for uncommon operating systems though.

This change adds the LIBCXX_HAS_PTHREAD_API cmake flag, which turns
into the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. This is
a name change from the old _LIBCPP_THREAD_API_PTHREAD. The lit tests
want __config_site.in variables to have a _LIBCPP_HAS prefix.

http://reviews.llvm.org/D20573


git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@270735 91177308-0d34-0410-b5e6-96231b3b80d8
2016-05-25 17:40:09 +00:00
Vasileios Kalintiris
579b42b413 Add initial support for the MUSL C library.
Summary:
This patch adds the LIBCXX_LIBC_IS_MUSL cmake option to allow the
building of libcxx with the Musl C library. The option is necessary as
Musl does not provide any predefined macro in order to test for its
presence, like GLIBC. Most of the changes specify the correct path to
choose through the various #if/#else constructs in the locale code.

Depends on D13407.

Reviewers: mclow.lists, jroelofs, EricWF

Subscribers: jfb, tberghammer, danalbert, srhines, cfe-commits

Differential Revision: http://reviews.llvm.org/D13673

git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@252457 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-09 10:21:04 +00:00
Evgeniy Stepanov
4f01aa8fb8 ABI versioning macros for libc++.
C++ macros and CMake options that specify the default ABI version of
the library, and can be overridden to pick up new ABI-changing
features.

git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@250254 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-13 23:48:28 +00:00
Eric Fiselier
73ffc78616 [libcxx] Capture configuration information when installing the libc++ headers
Summary:
Hi all,

This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread.

Please read the design documentation added in this patch for a description of how it works.

Reviewers: mclow.lists, danalbert, jroelofs, EricWF

Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits

Differential Revision: http://reviews.llvm.org/D13407

git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@250235 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-13 22:12:02 +00:00