The libc++ <__refstring> headers has no real reason why it should
be a public header that libc++ ships. The only reason it was in the include
directory was because libc++abi needed it to build the library.
However keeping <__refstring> a header had other problems, like requiring its
dependancies to also be in the headers. For that reason this patch
moves it into the source directory.
To work around libc++abi's need for this header a duplicated copy was added
to libc++abi in r307748. While duplicating the code is an unfortunate solution
it's the best solution that's currently possible.
In the future I would like to start a discussion on the mailing lists about
making libc++abi build as a sub-project of libc++, requiring the libc++ sources
always be present.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307749 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290849 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290839 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
`__libcpp_refstring` currently has two different definitions. First there is the complete definition in `<__refstring>` but there is also a second in `<stdexcept>`. The historical reason for this split is because both libc++ and libc++abi need to see the inline definitions of __libcpp_refstrings methods, but the `<stdexcept>` header doesn't. However this is an ODR violation and breaks the modules build.
This patch fixes the issue by creating a single class definition in `<stdexcept>` and changing `<__refstring>` to contain only the inline method definitions. This way both `libcxx/src/stdexcept.cpp` and `libcxxabi/src/stdexcept.cpp` see the same declaration in `<stdexcept>` and definitions in `<__refstring>`
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25603
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@285100 91177308-0d34-0410-b5e6-96231b3b80d8
This was put in to get libc++ building without libcxxabi. We now have
macros that show that we are building against libcxxabi so use that
instead. This guards against existing but broken cxxabi.h headers on the
system.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@250507 91177308-0d34-0410-b5e6-96231b3b80d8
compatibility to libstdc++. Move the implementation into a header for
easier sharing with libc++abi. Merge a number of improvements from that
version. Provide a POD definition for <stdexcept>'s public use to avoid
cast dances. Discussed with Marshall Clow.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@207695 91177308-0d34-0410-b5e6-96231b3b80d8
The __sync_add_and_fetch() builtin parameter is volatile but clang has
'different' type checking and ends up accepting this code.
Undo the C++ cast from r198505 to get libc++/LLVM building with g++ while this
is investigated.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@199494 91177308-0d34-0410-b5e6-96231b3b80d8
Linking against libstdc++, rather than libsupc++, is probably better
for people who need to link against clients of libstdc++. Because
libsupc++ is provided only as a static library, its globals are not
shared between the static library and the copy linked into libstdc++.
This has been found to cause at least one test failure.
This also removes a number of symbols which were multiply defined
between libstdc++ and libc++, only when linking with libstdc++.
Differential Revision: http://llvm-reviews.chandlerc.com/D1825
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@192075 91177308-0d34-0410-b5e6-96231b3b80d8
out of the box on Linux systems. If you're building against libc++abi, you
still need to make sure it can find <cxxabi.h> so it knows not to export
symbols which libc++abi provides.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@155091 91177308-0d34-0410-b5e6-96231b3b80d8
