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
The remaining multiple definitions were flushed out by attempting to
link libsupc++ and libc++ into the same executable with --whole-archive,
e.g.
clang++ -I../llvm/projects/libcxx/include -nodefaultlibs -Wl,--whole-archive lib/libc++.a /usr/lib/gcc/x86_64-linux-gnu/4.6/libsupc++.a -Wl,--no-whole-archive -lgcc -lgcc_s -lc -lpthread -lrt
(The same technique was used to flush out multiple definitions in
libstdc++.)
Differential Revision: http://llvm-reviews.chandlerc.com/D1824
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@192074 91177308-0d34-0410-b5e6-96231b3b80d8
I've changed it so we don't set highest level warnings (all) for MSVC when building projects using cmake and instead leave the default. That's /W4 on my machine and seems to be ok.
With all warnings on for msvc, we see literally thousands of warnings. 99.99% aren't relevant and just obscure the ones that are.
I think the user can still override things if they want something different from the command line when using cmake.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@192010 91177308-0d34-0410-b5e6-96231b3b80d8
The issue this patch seeks to address is that MS's compiler (cl.exe) doesn't support the __attribute__((__weak__)) or __atribute__((__visibility__("default")) syntax; so a solution must be found where cl.exe doesn't see this syntax.
This patch seeks to solve this problem by changing code patterned like this:
__attribute__((__weak__, __visibility__("default")))
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { /*snip*/; return p; }
to code like this:
_LIBCPP_WEAK
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { return p; }
Howard: Thanks for all the comments regarding the default visibility
tag on the definition. I agree it isn't needed, and that there are lots
of other places where it is missing. That being said, I'm not wanting
to rock the boat on that issue right now. So I've added it back to the
definition via _LIBCPP_FUNC_VIS. A later pass dedicated just to this
issue can bring things in to a consistent state one way or the other.
Note that we do not want to have the exact same attributes on the
declaration and defintion in this case. The declaration should not be
marked weak, whereas the definition should (which is what G M's patch
did). I've fully tested on OS X to ensure that the resultant attribute
syntax actually works.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@192007 91177308-0d34-0410-b5e6-96231b3b80d8
The patch touches these files:
locale
array
deque
new
string
utility
vector
__bit_reference
__split_buffer
locale_win32.h
There is no intended functionality change and it is expected that reversing the position of the inline keyword with regard to the other keywords does not change the meaning of anything, least not for apple/Linux etc.
It is intended to make libcxx more consistent with itself and to prevent the 1000 or so
"inline.cpp(3) : warning C4141: 'inline' : used more than once" warnings that MS's cl.exe compiler emits without this patch, i.e. if inline is not the first keyword before a function name etc.
Prefer "inline [other inline related keyword]" over "[other related keyword] inline".
After this patch, libcxx should be consistent to this pattern.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@191987 91177308-0d34-0410-b5e6-96231b3b80d8
libsupc++ declares these constructors inline, so we won't necessarily
get a definition for them in the library.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@191931 91177308-0d34-0410-b5e6-96231b3b80d8
libcxx doesn't build with -Werror because of #warnings in its source
code. But when libcxx is built as an external LLVM project, it inherits
LLVM build flags, breaking the build if LLVM_ENABLE_WERROR is enabled.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@191814 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise if libcxx is built as an LLVM external project (after r191624),
"include(config-ix)" will include config-ix.cmake from LLVM, not from libcxx,
which will result in misconfigured build tree.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@191657 91177308-0d34-0410-b5e6-96231b3b80d8
libsupc++ in typeinfo.cpp, bringing it into agreement with
exception.cpp. This fixes link errors due to duplicate symbols from
this translation unit.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@191397 91177308-0d34-0410-b5e6-96231b3b80d8
iterator, allocator) constructor with the intention of it being
implicitly converted to the allocator type, it is possible for overload
resolution to favour the (iterator, iterator, enable_if) constructor.
Eliminate this possibility by moving the enable_if to one of the
existing arguments and removing the third argument.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@191145 91177308-0d34-0410-b5e6-96231b3b80d8
