BUILD_HOST_static has been broken because I was stripping
-Wl,--start-group/-Wl,--end-group into a separate set of ldflags instead
of keeping them wrapped around some of the ldlibs. So don't pass some of
the build system flags through the ldlibs checker.
Bug: 30898128
Change-Id: I332b42679695cdc5da3cb0036290b6a3544699c0
Prevent platform modules from linking against libstdc++ as their STL
implementation. NDK modules may still use libstdc++.
Change-Id: I317c9bb90ca7d2e0c1f5770bbdff8075dfe3cc83
We've been including the system libc++ headers even if we're building
against our version of libc++. Stop doing that, and only add the headers
to our path if we're using the system libraries.
If nothing is specified, on recent OSX versions, libc++ is the default
c++ library instead of libstdc++. We've been explicitly including the
libc++ headers on all versions, but that breaks old versions. Force us
over to libc++, since the system libstdc++ does not support C++11, and
libc++ is still supported on our oldest version (10.8).
Change-Id: I1fccee8da0f425e10ccc9d3247ed40664eb6ada0
We still need to link the various MSVC libraries even if we aren't
using the STL.
Bug: http://b/22953515
Change-Id: I73c35710a6162408e99480a4840eedd291adf7ab
Instead of using recursive make to change the HOST_OS when building the
windows SDK under linux, add the concept of cross-building to another
host os.
Bug: 23566667
Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
These symbols need to always be resolved for each binary. Making these
symbols hidden means that we will get a build breakage if this doesn't
happen, and should also prevent the situation where one unwinder's
symbols are visible to the other.
Bug: 18471342
Bug: 19958712
Change-Id: Ieff1f10dab254b60ed120410f45998cf75bb5b9b
The only remaining users of stlport are vendor blobs. Prevent any new
users from using it.
Bug: http://b/15193147
Change-Id: I577a16c8c52e2c7d939c3b5026e18ad90e4b9f26
The previous check tested against USE_MINGW even for target builds.
Hadn't been a problem because people don't typically set USE_MINGW
directly.
Change-Id: I90fe0ea890c44917eb29dd02d7c7f76c19e7fbd6
After fixing the link order here, it seems libunwindbacktrace no
longer works for exception unwinding, but libgcc now does.
Change-Id: Ice79af4b8f234ed6a053ee818b6dec3aa9706c8a
Previously we were bundling this into libc++ and having each binary
resolve its symbols from there. This means that the unwinder that gets
used for a given binary is sensitive to the order in which its
libraries are linked. Making this a static library dependency of each
binary means the right unwinder will always be used.
Bug: 18471342
Bug: 19958712
Change-Id: I782d212784dbf85355b5d9146d7460d675259a0e
Can't be done on the user's end because these libraries all need to be
linked after libc++_static.
Change-Id: Ib21364e6f43689cf59da31d6f561919731ef8272
The Mac linker doesn't understand --start-group, which is needed for
properly linking libgcc/libc statically. It isn't needed for dynamic
executables though, so use that driver behavior where appropriate.
Bug: 19567451
Change-Id: Ifeb03bea55bc87561c64ddafdb99f664fef0f00e
BUILD_HOST_static=1 forces all host binaries to be statically linked.
Since -nodefaultlibs was passed (to disable libstdc++), libgcc wasn't
being passed. This change emulates the driver's behavior.
Also fix default STL selection for BUILD_HOST_static.
Bug: 19567451
Change-Id: I617aab782d40ac76ca5a7d9dddf0f202a4e3a69b
Previously, code defaulted to using libstdc++ (which was GNU libstdc++
on the host, or Bionic's "libstdc++" on the target). Now we default to
libc++. The exception for this is when using mingw, because we cannot
build libc++ for mingw.
Change-Id: I68726fa26cdcb6263f17c838d3e859debd57fae1
It is libstdc++.so, after all, and the naming makes sense for the host
this way (since it also uses libstdc++).
Change-Id: If37ffa015f7967a928ea47a290363d7696c4ce35
Because LOCAL_CXX_STL modifies a module's required shared libaries,
we need this for also prebuilt shared libraries and executables.
Change-Id: I418c26143999a613c40aadf990f131b123e0ac3d