There is no guaranteed order in which CMake files for individual
runtimes are invoked and therefore we cannot rely on existence of
targets defined in other runtimes. Use the new HAVE_<name> options
instead in those cases.
Differential Revision: https://reviews.llvm.org/D28391
llvm-svn: 291632
This is to make sure this check is called even when building as
part of LLVM runtimes when we are doing standalone but not out of
tree build.
Differential Revision: https://reviews.llvm.org/D28392
llvm-svn: 291592
Need to allow unresolved symbols in the dylib. This was previously done for
LIBCXX_HAS_EXTERNAL_THREAD_API, but we have since split that into two with
LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY being the externally-threaded variant.
Also a minor CMakeLists.txt cleanup.
llvm-svn: 291433
Summary:
This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses.
The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API.
Reviewers: compnerd, rmaprath
Subscribers: smeenai, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28316
llvm-svn: 291275
This patch re-commits a previous attempt to support building libc++ w/o
an ABI library. That patch was originally reverted because:
1) It forgot to teach the test suite about "default" ABI libraries.
2) Some LLVM builders don't clear the CMake cache between builds. The previous
patch caused those builders to fail since their old cache entry for
LIBCXX_CXX_ABI="" is no longer valid.
The updated patch addresses both issues. It works around (2) by adding
a hack to force the builders to update their cache entries. The hack will
be removed shortly once all LLVM builders have run.
Original commit message
-----------------------
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290849
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290839
Move the windows specific macro definitions for compiling c++ into the
target. Add a number of newer options that are necessary to properly
build libc++ for windows. This ensures that we do not accidentally
autolink msvcprt (Microsoft's C++ runtime library), do not define linker
pragmas which are msvcprt specific, and do not accidentally encode the
incorrect version of the msvc compatibility version.
llvm-svn: 290837
This allows us to build with cl (or rather clang-cl) by using the
correct spelling for `-include` (`/FI` for cl). clang-cl and cl default
to C++11/C++14 as they support it rather than permitting an explicit
language standard.
llvm-svn: 290802
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++ static to include in another library,
and we don't want any libc++ functions getting exported out of that
library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT.
Differential Revision: https://reviews.llvm.org/D26934
llvm-svn: 288690
This patch adds a `check-cxx-abilist` target which verifies the libc++.so ABI
when the current build configuration matches the configuration used to generate
the ABI lists.
In order to make this change `HandleOutOfTreeLLVM.cmake` needed to be modified
to include `LLVMConfig.cmake` so that `TARGET_TRIPLE` is defined. Hopefully
the changes needed to accommodate this won't break existing build
configurations.
llvm-svn: 286789
The runtimes subdir is the new location for runtimes, we should
include it when looking for libcxxabi headers.
Differential Revision: https://reviews.llvm.org/D26363
llvm-svn: 286333
Summary:
This patch turns on `-fvisibility-inlines-hidden` when building the dylib. This is important so that libc++.dylib doesn't accidentally export inline-functions which are ODR used somewhere in the dylib.
On OS X this change has no effect on the current ABI of the dylib. Unfortunately on Linux there are already ~20 inline functions which are unintentionally exported by the dylib. Almost all of these are implicitly generated destructors. I believe removing these function definitions is safe because every "linkage unit" which uses these functions has its own definition, and therefore shouldn't be dependent on libc++.dylib to provide them.
Also could a FreeBSD maintainer comment on the ABI compatibility of this patch?
Reviewers: mclow.lists, emaste, dexonsmith, joker-eph-DISABLED, jroelofs, danalbert, mehdi_amini, compnerd, dim
Subscribers: beanz, mgorny, cfe-commits, modocache
Differential Revision: https://reviews.llvm.org/D25593
llvm-svn: 285101
musl's pthread implementations use volatile types in their structs
which is not being constexpr in C++11 but is in C++14.
Differential Revision: https://reviews.llvm.org/D25491
llvm-svn: 284950
Libc++ will not build with modules enabled. In order to support an in-tree
libc++ when LLVM_ENABLE_MODULES is ON we need to explicitly disable the feature.
Unfortunately the libc++ sources are fundamentally non-modular. For example
iostream.cpp defines cout, cerr, wout, ... as char buffers instead of streams
in order to better control initialization/destruction. Not shockingly Clang
diagnoses this. Many other sources files define _LIBCPP_BUILDING_FOO macros to
provide definitions for normally inline symbols (See bind.cpp). Finally The
current module.map prohibits using <strstream> in C++11 so we can't build
strstream.cpp.
I think I can fix most of these issues but until then just disable modules.
llvm-svn: 284230
Introduce LIBCXX_LIBRARIES_PUBLIC in addition to LIBCXX_LIBRARIES that
holds 'public' interface libraries -- that is, libraries that both
libc++ links to and programs linked against it need to link to.
Currently this includes the ABI library and optionally -lunwind (when
LIBCXXABI_USE_LLVM_UNWINDER is on). The libraries are included in the
linker script, in order to make it possible to link C++ programs using
clang with compiler-rt runtime out-of-the-box.
Differential Revision: https://reviews.llvm.org/D25008
llvm-svn: 283659
Revert r282483 as it causes build failures due to missing symbols when
not linking to -lgcc_s (i.e. doing pure LLVM stack build). The patch can
be reintroduced when the build system is fixed to add all needed
libraries (libunwind, compiler-rt).
llvm-svn: 282524
Add the "-Wl,-z,defs" linker option that is used to prevent
underlinking. It is already used by LLVM itself but does not get
propagated into stand-alone build of libc++. This patch ensures
that the option is passed in independently of whether libc++ is built
in-tree or out-of-tree.
Patch by Lei Zhang.
Differential Revision: https://reviews.llvm.org/D24119
llvm-svn: 282483
Strip the set of flags (including debug defs, -m32) that could
be inherited from top-level LLVM build only when in-tree build is
performed. This prevents libcxx from confusingly and undesiredly
stripping user-supplied flags e.g. when performing packaging system
controlled multi-ABI build.
Otherwise, in order to perform 32-bit builds the build scripts would
have to use LIBCXX_BUILD_32_BITS. However, -m32 is only one of the many
different ABI flags for different targets, and it really makes no sense
to add separate CMake options for each possible -m* flag and then keep
a mapping from well-known flags to the custom CMake options.
Differential Revision: https://reviews.llvm.org/D24809
llvm-svn: 282475
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.
llvm-svn: 282449
Summary:
This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each!
This patch adds two new visibility macros:
* `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this.
* `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this.
After applying this patch GCC only emits one -Wattribute warning opposed to 30+.
Reviewers: mclow.lists, EricWF
Subscribers: beanz, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D24602
llvm-svn: 281673
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
llvm-svn: 281179
When libc++experimental was originally created it was empty and therefore there
was no reason to install it. Now that the library contains
<experimental/memory_resource> and <experimental/filesystem> there is a good
reason to install it.
Specifically this patch enables the installation whenever LIBCXX_INSTALL_LIBRARY
is true and LIBCPP_ENABLE_EXPERIMENTAL_LIBRARY is true.
llvm-svn: 280773
Summary:
Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are:
* Work around strict aliasing issues in `typeinfo::hash_code()` by using __attribute__((may_alias)). However I think a non-aliasing `hash_code()` implementation is possible. Further investigation needed.
* Add `_LIBCPP_UNREACHABLE()` to switch in `strstream.cpp` to avoid -Wpotentially-uninitialized.
* Fix -Wunused-value warning in `__all` by adding a void cast.
* Ignore -Wattributes for now. There are a number of real attribute issues when using GCC but enabling the warning is too noisy.
* Ignore -Wliteral-suffix since it warns about the use of reserved identifiers. Note Only GCC 7.0 supports disabling this warning.
* Ignore -Wc++14-compat since it warns about the sized new/delete overloads.
Reviewers: EricWF
Differential Revision: https://reviews.llvm.org/D24003
llvm-svn: 280007
This patch enables the `cxx-benchmarks` target by default. Note that the target
still has to be manually invoked since it isn't included in the default 'make'
rule.
This patch also gets the benchmarks building w/ GCC. The build previously
required the '-stdlib=libc++' flag but upstream patches to Google Benchmark
now allow the library to build w/ libc++ and GCC.
These changes should make the benchmarks easier to build and test.
llvm-svn: 279999
Summary:
The new LLVM runtimes build directory requires some basic conventions across the runtime projects. These changes make libcxx build under the runtimes subdirectory. The general idea of the changes is that the runtimes subdirectory requires some conventions to be consistent across runtime projects.
I expect to have a few more small patches that build on this to tie up check targets and other things useful in development workflows.
Summary of changes in this patch:
* Renamed variable LLVM_CONFIG -> LLVM_CONFIG_PATH
* Renamed variable LIBCXX_BUILT_STANDALONE -> LIBCXX_STANDALONE_BUILD
* Add an include of AddLLVM in the tests subdirectory for add_lit_testsuite.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23696
llvm-svn: 279151
Although libc++ only requires C++11 to build, there are other
reasons to turn on a newer dialect in the build. For example
IDE's may not highlight any C++14/C++17 in the headers when
configured for C++11. This patch add's a private option for
changing this.
llvm-svn: 278638
This change allows building both shared and static version of libc++
in a single build, sharing object files between both versions.
Differential Revision: https://reviews.llvm.org/D23232
llvm-svn: 278068
Summary:
This patch does the following:
1. Checks in a copy of the Google Benchmark library into the libc++ repo under `utils/google-benchmark`.
2. Teaches libc++ how to build Google Benchmark against both (A) in-tree libc++ and (B) the platforms native STL.
3. Allows performance benchmarks to be built as part of the libc++ build.
Building the benchmarks (and Google Benchmark) is off by default. It must be enabled using the CMake option `-DLIBCXX_INCLUDE_BENCHMARKS=ON`. When this option is enabled the tests under `libcxx/benchmarks` can be built using the `libcxx-benchmarks` target.
On Linux platforms where libstdc++ is the default STL the CMake option `-DLIBCXX_BUILD_BENCHMARKS_NATIVE_STDLIB=ON` can be used to build each benchmark test against libstdc++ as well. This is useful for comparing performance between standard libraries.
Support for benchmarks is currently very minimal. They must be manually run by the user and there is no mechanism for detecting performance regressions.
Known Issues:
* `-DLIBCXX_INCLUDE_BENCHMARKS=ON` is only supported for Clang, and not GCC, since the `-stdlib=libc++` option is needed to build Google Benchmark.
Reviewers: danalbert, dberlin, chandlerc, mclow.lists, jroelofs
Subscribers: chandlerc, dberlin, tberghammer, danalbert, srhines, hfinkel
Differential Revision: https://reviews.llvm.org/D22240
llvm-svn: 276049
From r229162:
Visual Studio's SAL extension uses a macro named __deallocate. This
macro is used pervasively
Using -Werror when building for Windows can force the use of -Wno-#warnings
specifically because of this __deallocate #warning. Instead of forcing
builds to disable all #warnings, this option allows libc++ to be built
without this particular warning, while leaving other #warnings enabled.
Patch by Dave Lee!
llvm-svn: 275172
fstream has a switch over ios_base::seekdir which provides a defensive default
case. This seems like the right thing for fstream to do, but we need to disable
clangs warning during the build to allow this.
llvm-svn: 273092
Add the completed std::experimental::filesystem implementation and tests.
The implementation supports C++11 or newer.
The TS is built as part of 'libc++experimental.a'. Users of the TS need to
manually link this library. Building and testing the TS can be disabled using
the CMake option '-DLIBCXX_ENABLE_FILESYSTEM=OFF'.
Currently 'libc++experimental.a' is not installed by default. To turn on the
installation of the library use '-DLIBCXX_INSTALL_EXPERIMENTAL_LIBRARY=ON'.
llvm-svn: 273034
Summary:
This patch changes the libc++ CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake.
Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed.
This patch fixes:
https://llvm.org/bugs/show_bug.cgi?id=24322
Reviewers: danalbert, jroelofs, bcraig, compnerd
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20887
llvm-svn: 271460
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
llvm-svn: 270735
This option is geared towards shared library builds and causes static
library builds to fail if not explicitly disabled.
This patch fixes PR27706: https://llvm.org/bugs/show_bug.cgi?id=27706
Thanks rgoodfel@isi.edu for the catch.
llvm-svn: 269585
Summary:
Out-of-line symbols for <experimental/...> headers are not ABI or API stable and cannot live in the 'libc++.dylib'. Currently they have nowhere to live. I would like to add a new library target `libc++experimental.a` to fix this.
Previously I had suggested different libraries for different TS's (`libc++filesystem.a`, 'libc++LFTS.a`, ect). I no longer think this is the right approach.
Instead `c++experimental` will hold *all* TS implementations as a single monolithic library. I see two main benefits to this:
1. Users only have to know about and manually link one library.
2. It makes it easy to implement TS's with one or two out-of-line symbols. (Ex. PMRs)
`c++experimental` provides NO ABI compatibility. Symbols can freely be added/removed/changed without concern for ABI stability.
I will add documentation for this after landing this patch (but before adding anything to it).
`c++experimental` only builds as a static library. By default CMake will build/test this library but will *NOT* install it.
This patch adds the CMake and LIT logic needed to build/test the new library. Once this lands I plan on using it to implement parts of `<experimental/memory_resource>`.
Reviewers: mclow.lists
Subscribers: cfe-commits, theraven, krememek, dexonsmith, bcraig, beanz, danalbert
Differential Revision: http://reviews.llvm.org/D19856
llvm-svn: 268443
Avoid the developer warnings from cmake when configuring libc++ as part of the
LLVM layout. Setup the custom macro paths earlier to re-use the detection logic
prior to setting the project properties.
llvm-svn: 260071
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
llvm-svn: 252457
Summary:
This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever `LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever:
1. WIN32 is not defined.
2 UNIX is defined.
3. APPLE is not defined.
While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we are asking I think it's close enough.
After committing this patch Linux users will no longer have to use "-lc++abi" explicitly!
Reviewers: mclow.lists, danalbert, compnerd, jroelofs
Subscribers: emaste, rengolin, cbergstrom, cfe-commits
Differential Revision: http://reviews.llvm.org/D13739
llvm-svn: 250469
Summary:
Currently on most platforms you have to manually link the c++ abi library used with libc++ whenever you use libc++. So your typical libc++ command like invocation might look like:
```
clang++ -stdlib=libc++ foo.cpp -lc++abi
```
Having to manually link `libc++abi.so` makes it harder for libc++ to be used generically. This patch fixes that by generating a linker script for `libc++.so` that correctly links the ABI library. On linux the linker script for libc++abi would look like:
```
# libc++.so
INPUT(libc++.so.1 -lc++abi)
```
With the linker script you can now use libc++ using only `-stdlib=libc++`. This is the technique that is used on FreeBSD in ordered to link cxxrt and I think it's the best approach to make our users lives simpler.
The CMake option used to enable this is `LIBCXX_ENABLE_ABI_LINKER_SCRIPT`. In future I would like to enable this by default on all platforms except for Darwin.
Reviewers: mclow.lists, danalbert, rsmith, jroelofs, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12508
llvm-svn: 250319
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.
llvm-svn: 250254
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
llvm-svn: 250235
Summary:
On Mac OS X overwriting `/usr/lib/libc++.dylib` can cause your computer to fail to boot. This patch tries to make it harder to do that accidentally.
If `CMAKE_SYSTEM_NAME` is `Darwin` and `CMAKE_INSTALL_PREFIX` is `/usr` don't generate installation rules unless the user explicitly provides `LIBCXX_OVERRIDE_DARWIN_INSTALL=ON`. Note that `CMAKE_INSTALL_PREFIX` is always absolute so we don't need to worry about things like `/usr/../usr`.
Reviewers: mclow.lists, beanz, jroelofs
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12209
llvm-svn: 246070
Summary:
This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++.
The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs
In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`.
Reviewers: chandlerc, mclow.lists, danalbert, jroelofs
Subscribers: silvas, cfe-commits
Differential Revision: http://reviews.llvm.org/D12129
llvm-svn: 245788
This patch adds the working parts of r243503. The difference with this patch
is that it doesn't include the HandleLLVMOptions.cmake file.
llvm-svn: 243698
This change was reverted in r243550 because it broke clang-format builds
(see PR24306).
This patch recommits a fixed version of the original.
llvm-svn: 243574
Summary:
This patch contains the following changes:
1. Require that libc++ can find a LLVM source directory. This is done the same way as `libc++abi` currently does.
2. Cleanup ugly configuration code in CMakeLists.txt by using `add_flags`, `add_flags_if`, and `add_flags_if_supported` macros.
The goals for this patch are:
1. Help libc++ be more consistent with how LLVM handles CMake options (see PR23670 PR23671).
2. Make it easier to use sanitizers using the `LLVM_USE_SANITIZER` option.
3. Make libc++'s CMakeLists.txt file easier to understand and change.
4. Move towards allowing libc++ to create Sphinx documentation (see http://efcs.ca/libcxx-docs).
5. Move towards allowing libc++ to use other LLVM utilities such as `not` and `FileCheck`.
Reviewers: mclow.lists, jroelofs, danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11308
llvm-svn: 243503
Although CMake adds warning flags, they are ignored in the libc++ headers
because the headers '#pragma system header' themselves.
This patch disables the system header pragma when building libc++ and fixes
the warnings that arose.
The warnings fixed were:
1. <memory> - anonymous structs are a GNU extension
2. <functional> - anonymous structs are a GNU extension.
3. <__hash_table> - Embedded preprocessor directives have undefined behavior.
4. <string> - Definition is missing noexcept from declaration.
5. <__std_stream> - Unused variable.
llvm-svn: 242623
One of the aspects of CloudABI is that it aims to help you write code
that is thread-safe out of the box. This is very important if you want
to write libraries that are easy to reuse. For CloudABI we decided to
not provide the thread-unsafe functions. So far this is working out
pretty well, as thread-unsafety issues are detected really early on.
The following patch adds a knob to libc++,
_LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS, that can be set to disable
thread-unsafe functions that can easily be avoided in practice. The
following functions are not thread-safe:
- <clocale>: locale handles should be preferred over setlocale().
- <cstdlib>: mbrlen(), mbrtowc() and wcrtomb() should be preferred over
their non-restartable counterparts.
- <ctime>: asctime(), ctime(), gmtime() and localtime() are not
thread-safe. The first two are also deprecated by POSIX.
Differential Revision: http://reviews.llvm.org/D8703
Reviewed by: marshall
llvm-svn: 240527
The test cases were crashing due to the mixed usage of the unwinding
functions from both libunwind and libgcc_s. The unwind functions are
mixed because the "llvm_unwinder" entry is not available in the
lit.site.cfg for libc++. As a result, "-lgcc_s" is picked instead of
"-lunwind". The extra option to lit --param=link_flags="-lunwind" won't
help either.
This CL fix the problem by adding llvm_unwinder to lit.site.cfg.in.
llvm-svn: 237518
Summary:
This patch adds configuration to CMake and LIT for running the libc++ test-suite to generate code coverage.
To use code coverage use following instructions.
* Find the clang resource dir using `$CXX -print-search-dirs`. Let <library-dir> be the first library search directory.
* `cmake <regular-options> -DLIBCXX_GENERATE_COVERAGE=ON -DLIBCXX_COVERAGE_LIBRARY=<library-dir>/lib/<platform>/libclang_rt.profile.a <source>`
* `make cxx`
* `make check-libcxx`
* `make generate-libcxx-coverage`
The reason I want this patch upstreamed is so I can setup a bot that generates code coverage and posts in online for every revision.
Reviewers: mclow.lists, jroelofs, danalbert
Reviewed By: danalbert
Differential Revision: http://reviews.llvm.org/D8716
llvm-svn: 233669
The idea behind Nuxi CloudABI is that it is targeted at (but not limited to)
running networked services in a sandboxed environment. The model behind stdin,
stdout and stderr is strongly focused on interactive tools in a command shell.
CloudABI does not support the notion of stdin and stdout, as 'standard
input/output' does not apply to services. The concept of stderr does makes
sense though, as services do need some mechanism to log error messages in a
uniform way.
This patch extends libc++ in such a way that std::cin and std::cout and the
associated <cstdio>/<cwchar> functions can be disabled through the flags
_LIBCPP_HAS_NO_STDIN and _LIBCPP_HAS_NO_STDOUT, respectively. At the same time
it attempts to clean up src/iostream.cpp a bit. Instead of using a single array
of mbstate_t objects and hardcoding the array indices, it creates separate
objects that declared next to the iostream objects and their buffers. The code
is also restructured by interleaving the construction and setup of c* and wc*
objects. That way it is more obvious that this is done identically.
The c* and wc* objects already have separate unit tests. Make use of this fact
by adding XFAILs in case libcpp-has-no-std* is set. That way the tests work in
both directions. If stdin or stdout is disabled, these tests will therefore
test for the absence of c* and wc*.
Differential Revision: http://reviews.llvm.org/D8340
llvm-svn: 233275
Summary:
Clean up all the different possible CMake options for specifying the ABI include paths into one CMake option named `LIBCXX_CXX_ABI_INCLUDE_PATHS`.
The documentation has been updated to reflect this change.
For the next week I have added explicit errors if any of the old flags is used. These errors inform users of the change and the new option to use.
Before committing the change I will announce this change on cfe-dev.
Reviewers: danalbert, mclow.lists
Reviewed By: danalbert, mclow.lists
Subscribers: jroelofs, cbergstrom, cfe-commits
Differential Revision: http://reviews.llvm.org/D5039
llvm-svn: 232762
Systems like FreeBSD's Capsicum and Nuxi CloudABI apply the concept of
capability-based security on the way processes can interact with the
filesystem API. It is no longer possible to interact with the VFS
through calls like open(), unlink(), rename(), etc. Instead, processes
are only allowed to interact with files and directories to which they
have been granted access. The *at() functions can be used for this
purpose.
This change adds a new config switch called
_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE. If set, all functionality
that requires the global filesystem namespace will be disabled. More
concretely:
- fstream's open() function will be removed.
- cstdio will no longer pull in fopen(), rename(), etc.
- The test suite's get_temp_file_name() will be removed. This will cause
all tests that use the global filesystem namespace to break, but will
at least make all the other tests run (as get_temp_file_name will not
build anyway).
It is important to mention that this change will make fstream rather
useless on those systems for now. Still, I'd rather not have fstream
disabled entirely, as it is of course possible to come up with an
extension for fstream that would allow access to local filesystem
namespaces (e.g., by adding an openat() member function).
Differential revision: http://reviews.llvm.org/D8194
Reviewed by: jroelofs (thanks!)
llvm-svn: 232049
Summary:
This patch add the CMake option `LIBCXX_ENABLE_STATIC_ABI_LIBRARY` which, when enabled, will link libc++ against the static version of the ABI library.
Reviewers: mclow.lists, jroelofs, danalbert
Reviewed By: danalbert
Subscribers: compnerd, cfe-commits
Differential Revision: http://reviews.llvm.org/D8017
llvm-svn: 231076
This isn't actually used for anything, and is broken on Darwin
(currently causing build failures now that the triple is passed to aid
cross compiling). Rather than fix unused code, just remove it.
llvm-svn: 226243
suffixes like 'lib64' or 'lib32'.
This support is currently very rhudimentary. We define a variable
LIBCXX_LIBDIR_SUFFIX. In a standalone build of libc++ this can be
directly set as a cached variable to control the multilib suffix used.
When building libc++ within a larger LLVM build, it is hard wired to
whatever LLVM libdir suffix has been selected. If this doesn't work for
someone, just let me know. I'm happy to change it.
This is essentially new functionality for libc++ so I don't expect it to
have any impact for folks until they start setting these variables.
However, I know libc++ is built in a diverse set of environments so just
let me know if this causes you any problems.
llvm-svn: 224926
Summary:
Currently to run tests in tree you need to symlink the lit.site.cfg file generated by the cmake build into the source tree, and teach your VCS to ignore it.
This allows the user to specify where to find the lit.site.cfg file two different ways:
* lit_site_config lit parameter
* LIT_SITE_CONFIG enviroment variable.
example usage:
```
lit -sv --param=libcxx_site_config=path/to/libcxx-build/test/lit.site.cfg path/to/tests
```
Or
```
export LIBCXX_SITE_CONFIG=path/to/libcxx-build/test/lit.site.cfg
lit -sv path/to/tests
```
The command line parameter will override the environment variable.
If neither options are present a warning is issued and the `lit.cfg` file is loaded directly.
Reviewers: mclow.lists, jroelofs, danalbert
Reviewed By: danalbert
Subscribers: ddunbar, cfe-commits
Differential Revision: http://reviews.llvm.org/D6255
llvm-svn: 224671
Currently hacks must be used in to configure and build libc++ without threads
when using CMake. This patch adds CMake options to enable/disable building with
threads and a monotonic clock.
This patch also propagates the configuration information to lit so the tests
are properly configured as well.
llvm-svn: 223591
Summary:
Currently we have 5 variables that are used to specify options for building libcxx
1. `LIBCXX_CXX_FEATURE_FLAGS`
2. `LIBCXX_CXX_WARNING_FLAGS`
3. `LIBCXX_CXX_REQUIRED_FLAGS`
4. `compile_flags` (in libcxx/lib)
5. `link_flags` (in libcxx/lib)
The first three all get put into `CMAKE_CXX_FLAGS`.
This changes the way flags are handled by only using 3 different options:
1. `LIBCXX_CXX_FLAGS` - general compile and link flags.
2. `LIBCXX_COMPILE_FLAGS` - compile only flags.
3. `LIBCXX_LINK_FLAGS` - link only flags.
This patch also removes the warning about `-nostdinc++` being unused during linking.
Reviewers: mclow.lists, danalbert
Reviewed By: danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6277
llvm-svn: 222080
Summary:
This patch adds support for building/testing libc++ with an ABI library that the linker would not normally find.
- `CMAKE_LIBRARY_PATH` is used to specify the list of search directories.
- The ABI library is now found using `find_library` instead of assuming its along the linker's search path.
- `CMAKE_LIBRARY_PATH` is passed to our LIT config as `library_paths`.
- For each path in `library_paths` the following flags are added `-L<path> -Wl,-rpath -Wl,<path>`
Some changes in existing behavior were also added:
- `target_link_libraries` is now passed the ABI library file instead of the library name. Ex `target_link_libraries(cxx "/usr/lib/libc++abi.so")` vs `target_link_libraries(cxx "c++abi")`.
- `-Wl,-rpath -Wl,<path>` is now used on OSX to link to libc++ instead of env['DYLD_LIBRARY_PATH'] if `use_system_lib=False`.
Reviewers: mclow.lists, danalbert, EricWF
Reviewed By: EricWF
Subscribers: emaste, cfe-commits
Differential Revision: http://reviews.llvm.org/D5038
llvm-svn: 220118
Petr Hosek