mac: Remove libc++ hack that was required by NaCl. NaCl target were still built with the 10.6 SDK even after we thought we switched the whole build to the 10.10 SDK. This was a problem in static library ASan builds: -fsanitize=address implicitly requires libc++, so this added a -lc++ to the link, but the 10.6 SDK doesn't contain a libc++ (since ASan requires 10.7, and since it also adds an implicit -lc++abi, we dynamically link libc++ in ASan builds). This led to linker errors. Now that NaCl targets build with the 10.10 SDK like everything else when they're part of a Chromium build, the hack I used to work around this is no longer needed, so remove it. No intended behavior change. BUG=400091 Review URL: https://codereview.chromium.org/1414703004 Cr-Commit-Position: refs/heads/master@{#356325}
diff --git a/build/common.gypi b/build/common.gypi index 56dc197..5b05435 100644 --- a/build/common.gypi +++ b/build/common.gypi
@@ -5260,15 +5260,27 @@ }, # configuration "Release" }, # configurations 'xcode_settings': { - # Everything should include libc++ headers. Just passing - # -stdlib=libc++ doesn't just work in NaCl targets with asan enabled - # until http://crbug.com/544325 is fixed, so tell the compiler to not - # add any include paths, and instead below add the c++ include - # directory as include_dirs. Then we can not set CLANG_CXX_LIBRARY - # to libc++ for NaCl targets and that way they'll link against - # libstdc++ on the ASan bots (ASan requires a C++ library to be linked - # even for the C-only NaCl programs). - 'OTHER_CPLUSPLUSFLAGS': [ '$inherited', '-nostdinc++', ], + # Tell the compiler to use libc++'s headers and the linker to link + # against libc++. The latter part normally requires OS X 10.7, + # but we still support running on 10.6. How does this work? Two + # parts: + # 1. Chromium's clang doesn't error on -mmacosx-version-min=10.6 + # combined with -stdlib=libc++ (it normally silently produced a + # binary that doesn't run on 10.6) + # 2. Further down, library_dirs is set to + # third_party/libc++-static, which contains a static + # libc++.a library. The linker then links against that instead + # of against /usr/lib/libc++.dylib when it sees the -lc++ flag + # added by the driver. + # + # In component builds, just link to the system libc++. This has + # the effect of making everything depend on libc++, which means + # component-build binaries won't run on 10.6 (no libc++ there), + # but for a developer-only configuration that's ok. (We don't + # want to raise the deployment target yet so that official and + # dev builds have the same deployment target. This affects + # things like which functions are considered deprecated.) + 'CLANG_CXX_LIBRARY': 'libc++', # -stdlib=libc++ 'GCC_DYNAMIC_NO_PIC': 'NO', # No -mdynamic-no-pic # (Equivalent to -fPIC) @@ -5286,42 +5298,8 @@ # specified or not. '-fno-strict-aliasing', # See http://crbug.com/32204. ], - 'conditions': [ - # TODO(thakis): Remove this condition once http://crbug.com/544325 - # is fixed. Some targets below native_client still link use the - # 10.6 SDK which doesn't contain a libc++. - ['mac_sdk!="10.6"', { - # Tell the compiler to use libc++'s headers and the linker to link - # against libc++. The latter part normally requires OS X 10.7, - # but we still support running on 10.6. How does this work? Two - # parts: - # 1. Chromium's clang doesn't error on -mmacosx-version-min=10.6 - # combined with -stdlib=libc++ (it normally silently produced a - # binary that doesn't run on 10.6) - # 2. Further down, library_dirs is set to - # third_party/libc++-static, which contains a static - # libc++.a library. The linker then links against that instead - # of against /usr/lib/libc++.dylib when it sees the -lc++ flag - # added by the driver. - # - # In component builds, just link to the system libc++. This has - # the effect of making everything depend on libc++, which means - # component-build binaries won't run on 10.6 (no libc++ there), - # but for a developer-only configuration that's ok. (We don't - # want to raise the deployment target yet so that official and - # dev builds have the same deployment target. This affects - # things like which functions are considered deprecated.) - 'CLANG_CXX_LIBRARY': 'libc++', # -stdlib=libc++ - - }], - ], }, 'target_conditions': [ - ['>(nacl_untrusted_build)==0', { - 'include_dirs': [ - '<(DEPTH)/third_party/llvm-build/Release+Asserts/include/c++/v1', - ], - }], ['>(nacl_untrusted_build)==0 and component=="static_library"', { # See the comment for CLANG_CXX_LIBRARY above for what this does. # The NaCl toolchains have their own toolchain and don't need this.
diff --git a/third_party/libc++-static/README.chromium b/third_party/libc++-static/README.chromium index e6f6efb0..092079d 100644 --- a/third_party/libc++-static/README.chromium +++ b/third_party/libc++-static/README.chromium
@@ -8,8 +8,8 @@ Revision: 245965 URL: http://libcxx.llvm.org/ -To upload: - python ~/depot_tools/upload_to_google_storage.py -b chromium-libcpp third_party/libc++-static.a +To upload (run automatically by build.sh): + upload_to_google_storage.py -b chromium-libcpp third_party/libc++-static/libc++.a To initialize gsutil's credentials: python ~/depot_tools/third_party/gsutil/gsutil config