Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1413863003:
mac: In static library builds, link against a static libc++.a (Closed)
|
Created:
5 years, 2 months ago by Nico Modified:
5 years, 2 months ago Reviewers:
Mark Mentovai CC:
chromium-reviews, eugenis Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
Descriptionmac: In static library builds, link against a static libc++.a
To achieve this, just add a -Lthird_party/libc++-static flag to the link line,
and add a postbuild that checks that Chromium Framework depends on neither
libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild
for this, and let it not run in component builds (since what it checks for
isn't interesting in that config, and we do depend on system libc++ in
component builds).
Also don't do this in asan builds. asan already requires OS X 10.7+.
And don't do this for targets below native_client, since those still
use the 10.6 SDK (!).
This change is small but subtle, see thread
"[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac"
and the document linked from comment 14 on the bug for details.
Ideally, this has no observable behavior change. If it looks like this
breaks tests somewhere, especially on 10.6, please revert. (The bots
like it, and the things I tried on 10.6 worked too, though.)
BUG=400091, 544325
R=mark@chromium.org
Committed: https://chromium.googlesource.com/chromium/src/+/494270d01189f8b4b2b4ebd501fd980833489729
Committed: https://chromium.googlesource.com/chromium/src/+/0f56cff872068cef226e7ad3f9701eb41d4eb2f5
Committed: https://crrev.com/f8a27cca3c79ca9c8f6bf701aa2cb8bbbc8b3059
Cr-Commit-Position: refs/heads/master@{#355966}
Patch Set 1 #
Total comments: 14
Patch Set 2 : comments #Patch Set 3 : missed a comment #Patch Set 4 : asan #Patch Set 5 : asan vs gyp scoping #Patch Set 6 : asan vs verify_order #Patch Set 7 : naaaaaacl #Patch Set 8 : hack #Patch Set 9 : haaaaack #
Messages
Total messages: 38 (17 generated)
thakis@chromium.org changed reviewers: + mark@chromium.org
mark: This is how this would look like. eugenis: Sicne you're doing some libc++ stuff upstream these days, maybe you want to comment on this, or on the doc linked from the bug. https://codereview.chromium.org/1413863003/diff/1/build/common.gypi File build/common.gypi (right): https://codereview.chromium.org/1413863003/diff/1/build/common.gypi#newcode5301 build/common.gypi:5301: '<(DEPTH)/third_party/libc++-static', The alternative here would be to use clang instead of clang++ to link our c++ code and then add the -lc++-static flag ourselves. We still need this -L flag then, but it's maybe a bit less surprising. In gyp, this would be possible with some gyp changes (currently, ldxx can't be overwritten) but gn hardcodes clang++ as linker, even for targets with C files only. This approach works without needing changes in both gyp and gn. https://codereview.chromium.org/1413863003/diff/1/chrome/tools/build/mac/veri... File chrome/tools/build/mac/verify_order (right): https://codereview.chromium.org/1413863003/diff/1/chrome/tools/build/mac/veri... chrome/tools/build/mac/verify_order:16: # Also check that the file does not depend on either of libstdc++ or libc++. Looks like this script currently also runs in component builds (where we do depend on libc++), so this doesn't quite work as-is. Options: 1. Don't run this script in component builds, it isn't useful there anyhow. 2. Do the lib(std)?c++ check in a separate script a) that runs only for Chromium Framework b) that runs for every executable and shared_library I kind of lean 1 (makes the build slightly faster, and should catch everything in practice), but I can see 2b happening too.
https://codereview.chromium.org/1413863003/diff/1/build/common.gypi File build/common.gypi (right): https://codereview.chromium.org/1413863003/diff/1/build/common.gypi#newcode5264 build/common.gypi:5264: # binary that doesn't run on 10.6) Is this a local change that we’ve made to clang, or is the error a local change that Apple has made in their own version? https://codereview.chromium.org/1413863003/diff/1/build/common.gypi#newcode5267 build/common.gypi:5267: # against that instead of again /usr/lib/libc++.dylib when it sees again → against https://codereview.chromium.org/1413863003/diff/1/build/common.gypi#newcode5301 build/common.gypi:5301: '<(DEPTH)/third_party/libc++-static', Nico (vacation Fri Oct 23) wrote: > The alternative here would be to use clang instead of clang++ to link our c++ > code and then add the -lc++-static flag ourselves. We still need this -L flag > then, but it's maybe a bit less surprising. In gyp, this would be possible with > some gyp changes (currently, ldxx can't be overwritten) but gn hardcodes clang++ > as linker, even for targets with C files only. This approach works without > needing changes in both gyp and gn. I think I slightly prefer what you’ve done here. https://codereview.chromium.org/1413863003/diff/1/chrome/tools/build/mac/veri... File chrome/tools/build/mac/verify_order (right): https://codereview.chromium.org/1413863003/diff/1/chrome/tools/build/mac/veri... chrome/tools/build/mac/verify_order:16: # Also check that the file does not depend on either of libstdc++ or libc++. On 2015/10/23 13:05:33, Nico (vacation Fri Oct 23) wrote: > Looks like this script currently also runs in component builds (where we do > depend on libc++), so this doesn't quite work as-is. > > Options: > 1. Don't run this script in component builds, it isn't useful there anyhow. > 2. Do the lib(std)?c++ check in a separate script > a) that runs only for Chromium Framework > b) that runs for every executable and shared_library > > I kind of lean 1 (makes the build slightly faster, and should catch everything > in practice), but I can see 2b happening too. Go (1). This script is pointless with component=shared_library. https://codereview.chromium.org/1413863003/diff/1/chrome/tools/build/mac/veri... chrome/tools/build/mac/verify_order:50: if grep -q libstdc++ <<< ${LIBS} ; then + has a special meaning in regular expressions. You need to add -F to turn off regex (like the other greps in this file do). Or you can use grep -Eq "lib(std)?c\+\" for a single grep to match both variants. https://codereview.chromium.org/1413863003/diff/1/third_party/libc++-static/b... File third_party/libc++-static/build.sh (right): https://codereview.chromium.org/1413863003/diff/1/third_party/libc++-static/b... third_party/libc++-static/build.sh:41: # size in each binary linking against libc++-static.a You can lose the -static off of this and the other things in this file too, since we’re calling it libc++.a now. .a is kind of obviously static anyway.
Thanks, good comments. https://codereview.chromium.org/1413863003/diff/1/build/common.gypi File build/common.gypi (right): https://codereview.chromium.org/1413863003/diff/1/build/common.gypi#newcode5264 build/common.gypi:5264: # binary that doesn't run on 10.6) On 2015/10/23 13:56:36, Mark Mentovai wrote: > Is this a local change that we’ve made to clang, or is the error a local change > that Apple has made in their own version? That's a local change Apple has in their branch. We don't have any local changes in our clang, it's pure upstream. Apple did upstream their change long ago in http://llvm.org/viewvc/llvm-project?rev=141374&view=rev but people complained that that broke their libc++ + 10.6 experiments, so they reverted it again http://llvm.org/viewvc/llvm-project?rev=141566&view=rev and now they're carrying that as a downstream diff. https://codereview.chromium.org/1413863003/diff/1/build/common.gypi#newcode5267 build/common.gypi:5267: # against that instead of again /usr/lib/libc++.dylib when it sees On 2015/10/23 13:56:36, Mark Mentovai wrote: > again → against Done. https://codereview.chromium.org/1413863003/diff/1/chrome/tools/build/mac/veri... File chrome/tools/build/mac/verify_order (right): https://codereview.chromium.org/1413863003/diff/1/chrome/tools/build/mac/veri... chrome/tools/build/mac/verify_order:16: # Also check that the file does not depend on either of libstdc++ or libc++. On 2015/10/23 13:56:36, Mark Mentovai wrote: > On 2015/10/23 13:05:33, Nico (vacation Fri Oct 23) wrote: > > Looks like this script currently also runs in component builds (where we do > > depend on libc++), so this doesn't quite work as-is. > > > > Options: > > 1. Don't run this script in component builds, it isn't useful there anyhow. > > 2. Do the lib(std)?c++ check in a separate script > > a) that runs only for Chromium Framework > > b) that runs for every executable and shared_library > > > > I kind of lean 1 (makes the build slightly faster, and should catch everything > > in practice), but I can see 2b happening too. > > Go (1). This script is pointless with component=shared_library. Done. https://codereview.chromium.org/1413863003/diff/1/chrome/tools/build/mac/veri... chrome/tools/build/mac/verify_order:50: if grep -q libstdc++ <<< ${LIBS} ; then On 2015/10/23 13:56:36, Mark Mentovai wrote: > + has a special meaning in regular expressions. You need to add -F to turn off > regex (like the other greps in this file do). Or you can use grep -Eq > "lib(std)?c\+\" for a single grep to match both variants. Done.
Description was changed from ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. BUG=400091 ========== to ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. BUG=400091 ==========
LGTM https://codereview.chromium.org/1413863003/diff/1/third_party/libc++-static/b... File third_party/libc++-static/build.sh (right): https://codereview.chromium.org/1413863003/diff/1/third_party/libc++-static/b... third_party/libc++-static/build.sh:41: # size in each binary linking against libc++-static.a Mark Mentovai wrote: > You can lose the -static off of this and the other things in this file too, > since we’re calling it libc++.a now. .a is kind of obviously static anyway. Not done?
Description was changed from ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. BUG=400091 ========== to ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. If it looks like this breaks tests somewhere, especially on 10.6, please revert. (The bots like it, and the things I tried on 10.6 worked too, though.) BUG=400091 ==========
https://codereview.chromium.org/1413863003/diff/1/third_party/libc++-static/b... File third_party/libc++-static/build.sh (right): https://codereview.chromium.org/1413863003/diff/1/third_party/libc++-static/b... third_party/libc++-static/build.sh:41: # size in each binary linking against libc++-static.a On 2015/10/23 16:46:07, Mark Mentovai wrote: > Mark Mentovai wrote: > > You can lose the -static off of this and the other things in this file too, > > since we’re calling it libc++.a now. .a is kind of obviously static anyway. > > Not done? Whoops, sorry. Done now.
The CQ bit was checked by thakis@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from mark@chromium.org Link to the patchset: https://codereview.chromium.org/1413863003/#ps40001 (title: "missed a comment")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1413863003/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1413863003/40001
LGTM
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/494270d01189f8b4b2b4ebd501fd980833489729 Cr-Commit-Position: refs/heads/master@{#355826}
Message was sent while issue was closed.
Committed patchset #3 (id:40001) manually as 494270d01189f8b4b2b4ebd501fd980833489729 (presubmit successful).
Message was sent while issue was closed.
A revert of this CL (patchset #3 id:40001) has been created in https://codereview.chromium.org/1424573002/ by thakis@chromium.org. The reason for reverting is: Broke Mac ASan x64: http://build.chromium.org/p/chromium.memory/builders/Mac%20ASan%2064%20Builde... FAILED: /b/build/goma/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang -Wl,-search_paths_first -fsanitize=address -Wl,-pie -Wl,-u,__sanitizer_options_link_helper -Wl,-dead_strip -mmacosx-version-min=10.6 -isysroot /Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk -arch x86_64 -L. -stdlib=libc++ -o tls_edit obj/native_client/src/tools/tls_edit/tls_edit.tls_edit.o libsanitizer_options.a libplatform.a librdfa_validator.a libgio.a '-L../../third_party/libc++-static' && (export BUILT_FRAMEWORKS_DIR=/b/build/slave/Mac_ASan_64_Builder/build/src/out/Release; export BUILT_PRODUCTS_DIR=/b/build/slave/Mac_ASan_64_Builder/build/src/out/Release; export CONFIGURATION=Release; export EXECUTABLE_NAME=tls_edit; export EXECUTABLE_PATH=tls_edit; export FULL_PRODUCT_NAME=tls_edit; export PRODUCT_NAME=tls_edit; export PRODUCT_TYPE=com.apple.product-type.tool; export SDKROOT=/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk; export SRCROOT=/b/build/slave/Mac_ASan_64_Builder/build/src/out/Release/../../native_client/src/tools/tls_edit; export SOURCE_ROOT="${SRCROOT}"; export TARGET_BUILD_DIR=/b/build/slave/Mac_ASan_64_Builder/build/src/out/Release; export TEMP_DIR="${TMPDIR}"; (cd ../../native_client/src/tools/tls_edit && ../../../../build/mac/change_mach_o_flags_from_xcode.sh && ../../../../build/mac/strip_from_xcode); G=$?; ((exit $G) || rm -rf tls_edit) && exit $G) ld: library not found for -lc++abi.
Message was sent while issue was closed.
Description was changed from ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. If it looks like this breaks tests somewhere, especially on 10.6, please revert. (The bots like it, and the things I tried on 10.6 worked too, though.) BUG=400091 R=mark@chromium.org Committed: https://chromium.googlesource.com/chromium/src/+/494270d01189f8b4b2b4ebd501fd... ========== to ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. If it looks like this breaks tests somewhere, especially on 10.6, please revert. (The bots like it, and the things I tried on 10.6 worked too, though.) BUG=400091 R=mark@chromium.org Committed: https://chromium.googlesource.com/chromium/src/+/494270d01189f8b4b2b4ebd501fd... ==========
Message was sent while issue was closed.
Patchset 4 (id:??) landed as https://crrev.com/0f56cff872068cef226e7ad3f9701eb41d4eb2f5 Cr-Commit-Position: refs/heads/master@{#355848}
Message was sent while issue was closed.
Committed patchset #4 (id:60001) manually as 0f56cff872068cef226e7ad3f9701eb41d4eb2f5 (presubmit successful).
Message was sent while issue was closed.
On 2015/10/23 18:53:29, Nico (vacation Fri Oct 23) wrote: > Committed patchset #4 (id:60001) manually as > 0f56cff872068cef226e7ad3f9701eb41d4eb2f5 (presubmit successful). still seems broken? http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac%20Builder/b...
Message was sent while issue was closed.
A revert of this CL (patchset #4 id:60001) has been created in https://codereview.chromium.org/1424593003/ by dalecurtis@chromium.org. The reason for reverting is: Failed lots of bots still :( Some in runhooks with: Using overrides found in /Users/chrome-bot/.gyp/include.gypi gyp: name 'asan' is not defined while evaluating condition '0==0 and component=="static_library" and asan==0' in /b/build/slave/Mac/build/src/third_party/pdfium/pdfium.gyp http://build.chromium.org/p/chromium/buildstatus?builder=Mac&number=8563 Some with compile errors: FAILED: /b/build/goma/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang -Wl,-search_paths_first ... ld: library not found for -lc++ http://build.chromium.org/p/chromium.memory/buildstatus?builder=Mac%20ASan%20....
Message was sent while issue was closed.
Description was changed from ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. If it looks like this breaks tests somewhere, especially on 10.6, please revert. (The bots like it, and the things I tried on 10.6 worked too, though.) BUG=400091 R=mark@chromium.org Committed: https://chromium.googlesource.com/chromium/src/+/494270d01189f8b4b2b4ebd501fd... Committed: https://chromium.googlesource.com/chromium/src/+/0f56cff872068cef226e7ad3f970... ========== to ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. If it looks like this breaks tests somewhere, especially on 10.6, please revert. (The bots like it, and the things I tried on 10.6 worked too, though.) BUG=400091 R=mark@chromium.org Committed: https://chromium.googlesource.com/chromium/src/+/494270d01189f8b4b2b4ebd501fd... Committed: https://chromium.googlesource.com/chromium/src/+/0f56cff872068cef226e7ad3f970... ==========
Description was changed from ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. If it looks like this breaks tests somewhere, especially on 10.6, please revert. (The bots like it, and the things I tried on 10.6 worked too, though.) BUG=400091 R=mark@chromium.org Committed: https://chromium.googlesource.com/chromium/src/+/494270d01189f8b4b2b4ebd501fd... Committed: https://chromium.googlesource.com/chromium/src/+/0f56cff872068cef226e7ad3f970... ========== to ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). Also don't do this in asan builds. asan already requires OS X 10.7+. This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. If it looks like this breaks tests somewhere, especially on 10.6, please revert. (The bots like it, and the things I tried on 10.6 worked too, though.) BUG=400091 R=mark@chromium.org Committed: https://chromium.googlesource.com/chromium/src/+/494270d01189f8b4b2b4ebd501fd... Committed: https://chromium.googlesource.com/chromium/src/+/0f56cff872068cef226e7ad3f970... ==========
Description was changed from ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). Also don't do this in asan builds. asan already requires OS X 10.7+. This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. If it looks like this breaks tests somewhere, especially on 10.6, please revert. (The bots like it, and the things I tried on 10.6 worked too, though.) BUG=400091 R=mark@chromium.org Committed: https://chromium.googlesource.com/chromium/src/+/494270d01189f8b4b2b4ebd501fd... Committed: https://chromium.googlesource.com/chromium/src/+/0f56cff872068cef226e7ad3f970... ========== to ========== mac: In static library builds, link against a static libc++.a To achieve this, just add a -Lthird_party/libc++-static flag to the link line, and add a postbuild that checks that Chromium Framework depends on neither libstdc++.dylib nor libc++.dylib Use the existing verify_order postbuild for this, and let it not run in component builds (since what it checks for isn't interesting in that config, and we do depend on system libc++ in component builds). Also don't do this in asan builds. asan already requires OS X 10.7+. And don't do this for targets below native_client, since those still use the 10.6 SDK (!). This change is small but subtle, see thread "[chromium-dev] Intent to implement: Statically linking libc++ for Chrome/Mac" and the document linked from comment 14 on the bug for details. Ideally, this has no observable behavior change. If it looks like this breaks tests somewhere, especially on 10.6, please revert. (The bots like it, and the things I tried on 10.6 worked too, though.) BUG=400091,544325 R=mark@chromium.org Committed: https://chromium.googlesource.com/chromium/src/+/494270d01189f8b4b2b4ebd501fd... Committed: https://chromium.googlesource.com/chromium/src/+/0f56cff872068cef226e7ad3f970... ==========
The CQ bit was checked by thakis@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from mark@chromium.org Link to the patchset: https://codereview.chromium.org/1413863003/#ps120001 (title: "naaaaaacl")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1413863003/120001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1413863003/120001
The CQ bit was checked by thakis@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from mark@chromium.org Link to the patchset: https://codereview.chromium.org/1413863003/#ps140001 (title: "hack")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1413863003/140001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1413863003/140001
The CQ bit was checked by thakis@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from mark@chromium.org Link to the patchset: https://codereview.chromium.org/1413863003/#ps160001 (title: "haaaaack")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1413863003/160001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1413863003/160001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by thakis@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1413863003/160001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1413863003/160001
Message was sent while issue was closed.
Committed patchset #9 (id:160001)
Message was sent while issue was closed.
Patchset 9 (id:??) landed as https://crrev.com/f8a27cca3c79ca9c8f6bf701aa2cb8bbbc8b3059 Cr-Commit-Position: refs/heads/master@{#355966} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
