Roll Clang 217949:218707 (+r218742 and r218921)

Roll Clang 217949:218707 (+r218742 and r218921)

Update the plugin cmake files to explicitly depend on Clang. When we moved
to the approach of building tools and plugins inside the LLVM build in
https://codereview.chromium.org/615083006/, that dependency was lost. We should
find a better way to do this eventually.

Also move the code to clear the CHROME_TOOLS_SHIM_DIR earlier in the script
to avoid having it affect the bootstrap build.

BUG=420674
NOTRY=true

Committed: https://crrev.com/51709a2ce53da80b7814b9244fb874e185e50566
Cr-Commit-Position: refs/heads/master@{#299766}

[hans, 2014-10-08 23:58:40]

hans@chromium.org changed reviewers:
+ thakis@chromium.org

[hans, 2014-10-08 23:58:41]

Please take a look.

Whitespace tryjobs: https://codereview.chromium.org/405473002/

My only tryjob concern was mac_asan_64's nacl_integration tests. I tried to
reproduce those locally, but get the same errors both with and without the roll
on my Mac, so I don't think we're regressing anything.

Cherrypicks: r218742 XFAIL's a test that fails on Darwin. The other one fixes a
thread safety and performance issue. We probably don't need it for correctness
as we never run two LLVM instances in a process, but this is what they released
internally.

[Nico, 2014-10-11 01:04:57]

cherrypicks = :-(

lgtm if someone is urgently waiting for this. Update CL description to explain
the unrelated changes other than upping the rev and adding cherrypicks.

https://codereview.chromium.org/630163005/diff/1/tools/clang/plugins/CMakeLis...
File tools/clang/plugins/CMakeLists.txt (right):

https://codereview.chromium.org/630163005/diff/1/tools/clang/plugins/CMakeLis...
tools/clang/plugins/CMakeLists.txt:7: add_dependencies(libFindBadConstructs
clang)
why these changes?

https://codereview.chromium.org/630163005/diff/1/tools/clang/scripts/update.sh
File tools/clang/scripts/update.sh (right):

https://codereview.chromium.org/630163005/diff/1/tools/clang/scripts/update.s...
tools/clang/scripts/update.sh:249: rm -rfv ${CHROME_TOOLS_SHIM_DIR}
Why is this moving up here?

[hans, 2014-10-11 04:31:46]

On 2014/10/11 01:04:57, Nico (away until Oct 27) wrote:
> cherrypicks = :-(

I know :/ The internal releases seem to typically come with cherrypicks these
days, though. We could try skipping r218921 and see how bad the compile-time
regression is, but I'd rather just take the cherry-pick.

> lgtm if someone is urgently waiting for this. Update CL description to explain
> the unrelated changes other than upping the rev and adding cherrypicks.

Most demand is coming from folks who want the plugins rolled to pick up the
changes that handle  override & final diagnostics. This roll would also fix
PR21036 for that precompiled headers thing, and there was someone waiting for a
UBSan fix too.

I'll get the description updated.

https://codereview.chromium.org/630163005/diff/1/tools/clang/plugins/CMakeLis...
File tools/clang/plugins/CMakeLists.txt (right):

https://codereview.chromium.org/630163005/diff/1/tools/clang/plugins/CMakeLis...
tools/clang/plugins/CMakeLists.txt:7: add_dependencies(libFindBadConstructs
clang)
On 2014/10/11 01:04:57, Nico (away until Oct 27) wrote:
> why these changes?

https://codereview.chromium.org/615083006/, which makes us build the tools and
plugins in-tree doesn't add a dependency edge from the plugins to clang. So the
build would fail if e.g. generated sources (like Attrs.inc) in clang aren't
built when the plugin builds.

This makes it build for the time being, but it's not very nice. Maybe we need to
go back to copying the files into the tree :/

https://codereview.chromium.org/630163005/diff/1/tools/clang/scripts/update.sh
File tools/clang/scripts/update.sh (right):

https://codereview.chromium.org/630163005/diff/1/tools/clang/scripts/update.s...
tools/clang/scripts/update.sh:249: rm -rfv ${CHROME_TOOLS_SHIM_DIR}
On 2014/10/11 01:04:57, Nico (away until Oct 27) wrote:
> Why is this moving up here?

So that the "shim" dir is not in the source tree when we build the bootstrap
compiler.

[hans, 2014-10-13 17:00:16]

I've updated the description, and I think we have enough demand that we should
take this roll despite having to cherry-pick.

Taking it to the cq.

[hans, 2014-10-13 17:00:20]

The CQ bit was checked by hans@chromium.org

[commit-bot: I haz the power, 2014-10-13 17:01:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/630163005/1

[Nico, 2014-10-13 17:01:49]

kk

On Mon, Oct 13, 2014 at 10:00 AM, <hans@chromium.org> wrote:

> I've updated the description, and I think we have enough demand that we
> should
> take this roll despite having to cherry-pick.
>
> Taking it to the cq.
>
> https://codereview.chromium.org/630163005/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[commit-bot: I haz the power, 2014-10-13 17:10:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-10-13 17:10:06]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[hans, 2014-10-13 17:36:12]

The CQ bit was checked by hans@chromium.org

[commit-bot: I haz the power, 2014-10-13 17:37:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/630163005/1

[commit-bot: I haz the power, 2014-10-13 17:45:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-10-13 17:45:35]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[hans, 2014-10-13 18:01:41]

The CQ bit was checked by hans@chromium.org

[commit-bot: I haz the power, 2014-10-13 18:03:16]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/630163005/1

[commit-bot: I haz the power, 2014-10-13 18:12:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-10-13 18:12:36]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[hans, 2014-10-13 21:00:32]

The android_clang_dbg_recipe looks like a real failure. Could be related to the
build target renaming of 218605.

[hans, 2014-10-13 22:02:43]

samsonov: I think the Android link failure is because of your r218541. -nostdlib
is being passed to the linker, and so the link fails:
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...

I'm not sure how that's supposed to work though.

[chromium-reviews, 2014-10-13 22:21:24]

Yes, looks like my change is the culprit. Linker invocation line I see
makes little sense to me: it has "-nostdlib" and a bunch of flags that are
supposed to link in system libraries (-ldl, -lc, -lm, -fsanitize=address).
That is, I think that Clang behavior is now correct.

On Mon, Oct 13, 2014 at 3:02 PM, <hans@chromium.org> wrote:

> samsonov: I think the Android link failure is because of your r218541.
> -nostdlib
> is being passed to the linker, and so the link fails:
> http://build.chromium.org/p/tryserver.chromium.linux/
> builders/android_clang_dbg_recipe/builds/12309/steps/
> compile%20%28with%20patch%29/logs/stdio
>
> I'm not sure how that's supposed to work though.
>
> https://codereview.chromium.org/630163005/
>



-- 
Alexey Samsonov, Mountain View, CA

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[hans, 2014-10-13 22:28:18]

It seems the Android build always uses -nostdlib:
https://code.google.com/p/chromium/codesearch#chromium/src/build/common.gypi&...

Presumably because it wants more control over the link line.

If that's the motivation, maybe they should also explicitly link in
the asan runtime?

On Mon, Oct 13, 2014 at 3:21 PM, Alexey Samsonov <samsonov@google.com> wrote:
> Yes, looks like my change is the culprit. Linker invocation line I see makes
> little sense to me: it has "-nostdlib" and a bunch of flags that are
> supposed to link in system libraries (-ldl, -lc, -lm, -fsanitize=address).
> That is, I think that Clang behavior is now correct.
>
> On Mon, Oct 13, 2014 at 3:02 PM, <hans@chromium.org> wrote:
>>
>> samsonov: I think the Android link failure is because of your r218541.
>> -nostdlib
>> is being passed to the linker, and so the link fails:
>>
>>
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...
>>
>> I'm not sure how that's supposed to work though.
>>
>> https://codereview.chromium.org/630163005/
>
>
>
>
> --
> Alexey Samsonov, Mountain View, CA

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2014-10-13 22:40:57]

That's kind of tricky - we need both -lasan and -L/path/to/asan/runtime in
that case. The latter is Clang resource path, somewhere
under third_party/llvm-build/Release+Asserts/lib/clang/..., and it's not
nice to hardcode it.

On Mon, Oct 13, 2014 at 3:27 PM, Hans Wennborg <hans@chromium.org> wrote:

> It seems the Android build always uses -nostdlib:
>
>
https://code.google.com/p/chromium/codesearch#chromium/src/build/common.gypi&...
>
> Presumably because it wants more control over the link line.
>
> If that's the motivation, maybe they should also explicitly link in
> the asan runtime?
>
> On Mon, Oct 13, 2014 at 3:21 PM, Alexey Samsonov <samsonov@google.com>
> wrote:
> > Yes, looks like my change is the culprit. Linker invocation line I see
> makes
> > little sense to me: it has "-nostdlib" and a bunch of flags that are
> > supposed to link in system libraries (-ldl, -lc, -lm,
> -fsanitize=address).
> > That is, I think that Clang behavior is now correct.
> >
> > On Mon, Oct 13, 2014 at 3:02 PM, <hans@chromium.org> wrote:
> >>
> >> samsonov: I think the Android link failure is because of your r218541.
> >> -nostdlib
> >> is being passed to the linker, and so the link fails:
> >>
> >>
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...
> >>
> >> I'm not sure how that's supposed to work though.
> >>
> >> https://codereview.chromium.org/630163005/
> >
> >
> >
> >
> > --
> > Alexey Samsonov, Mountain View, CA
>



-- 
Alexey Samsonov, Mountain View, CA

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[hans, 2014-10-13 22:47:21]

So should we change Clang back to adding it to the command line, since
it knows the exact location, etc.

It seems odd not to add it when -fsanitize=address is specified anyway
- that flag seems pretty useless without the runtime?

On Mon, Oct 13, 2014 at 3:40 PM, Alexey Samsonov <samsonov@google.com> wrote:
> That's kind of tricky - we need both -lasan and -L/path/to/asan/runtime in
> that case. The latter is Clang resource path, somewhere under
> third_party/llvm-build/Release+Asserts/lib/clang/..., and it's not nice to
> hardcode it.
>
> On Mon, Oct 13, 2014 at 3:27 PM, Hans Wennborg <hans@chromium.org> wrote:
>>
>> It seems the Android build always uses -nostdlib:
>>
>>
https://code.google.com/p/chromium/codesearch#chromium/src/build/common.gypi&...
>>
>> Presumably because it wants more control over the link line.
>>
>> If that's the motivation, maybe they should also explicitly link in
>> the asan runtime?
>>
>> On Mon, Oct 13, 2014 at 3:21 PM, Alexey Samsonov <samsonov@google.com>
>> wrote:
>> > Yes, looks like my change is the culprit. Linker invocation line I see
>> > makes
>> > little sense to me: it has "-nostdlib" and a bunch of flags that are
>> > supposed to link in system libraries (-ldl, -lc, -lm,
>> > -fsanitize=address).
>> > That is, I think that Clang behavior is now correct.
>> >
>> > On Mon, Oct 13, 2014 at 3:02 PM, <hans@chromium.org> wrote:
>> >>
>> >> samsonov: I think the Android link failure is because of your r218541.
>> >> -nostdlib
>> >> is being passed to the linker, and so the link fails:
>> >>
>> >>
>> >>
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...
>> >>
>> >> I'm not sure how that's supposed to work though.
>> >>
>> >> https://codereview.chromium.org/630163005/
>> >
>> >
>> >
>> >
>> > --
>> > Alexey Samsonov, Mountain View, CA
>
>
>
>
> --
> Alexey Samsonov, Mountain View, CA

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2014-10-13 22:57:43]

We have specifically added this logic for the following use case: when
people want their build system to produce ASan-ified binary, they generally
just add "-fsanitize=address" to their compile and link flags.
However, there are cases when we don't want to link in ASan runtime, for
example:
1) we don't link in static ASan runtime into shared objects (that's because
our runtime works this way).
2) we don't link in ASan runtime if -nostdlib is provided. If user is
passing this flag to linker, he essentially says "I know what I'm doing"
and is building a hermetic binary, with no extra dependencies.
  However, ASan runtime *does* bring extra dependencies - it depends on
libdl, libpthread, libc and librt. Linking it into the binary in this case
will likely just produce a linker errors due to unresolved symbols.

IMO Android linker invocation in question shouldn't have -nostdlib flag -
the resulting binary is expected to be dynamically linked to system
libraries from sysroot.

On Mon, Oct 13, 2014 at 3:46 PM, Hans Wennborg <hans@chromium.org> wrote:

> So should we change Clang back to adding it to the command line, since
> it knows the exact location, etc.
>
> It seems odd not to add it when -fsanitize=address is specified anyway
> - that flag seems pretty useless without the runtime?
>
> On Mon, Oct 13, 2014 at 3:40 PM, Alexey Samsonov <samsonov@google.com>
> wrote:
> > That's kind of tricky - we need both -lasan and -L/path/to/asan/runtime
> in
> > that case. The latter is Clang resource path, somewhere under
> > third_party/llvm-build/Release+Asserts/lib/clang/..., and it's not nice
> to
> > hardcode it.
> >
> > On Mon, Oct 13, 2014 at 3:27 PM, Hans Wennborg <hans@chromium.org>
> wrote:
> >>
> >> It seems the Android build always uses -nostdlib:
> >>
> >>
>
https://code.google.com/p/chromium/codesearch#chromium/src/build/common.gypi&...
> >>
> >> Presumably because it wants more control over the link line.
> >>
> >> If that's the motivation, maybe they should also explicitly link in
> >> the asan runtime?
> >>
> >> On Mon, Oct 13, 2014 at 3:21 PM, Alexey Samsonov <samsonov@google.com>
> >> wrote:
> >> > Yes, looks like my change is the culprit. Linker invocation line I see
> >> > makes
> >> > little sense to me: it has "-nostdlib" and a bunch of flags that are
> >> > supposed to link in system libraries (-ldl, -lc, -lm,
> >> > -fsanitize=address).
> >> > That is, I think that Clang behavior is now correct.
> >> >
> >> > On Mon, Oct 13, 2014 at 3:02 PM, <hans@chromium.org> wrote:
> >> >>
> >> >> samsonov: I think the Android link failure is because of your
> r218541.
> >> >> -nostdlib
> >> >> is being passed to the linker, and so the link fails:
> >> >>
> >> >>
> >> >>
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...
> >> >>
> >> >> I'm not sure how that's supposed to work though.
> >> >>
> >> >> https://codereview.chromium.org/630163005/
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Alexey Samsonov, Mountain View, CA
> >
> >
> >
> >
> > --
> > Alexey Samsonov, Mountain View, CA
>



-- 
Alexey Samsonov, Mountain View, CA

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[hans, 2014-10-13 23:04:41]

+michaelbai who committed the common.gypi lines adding -nostdlib
+eugenis who knows the android asan build the best

On Mon, Oct 13, 2014 at 3:57 PM, Alexey Samsonov <samsonov@google.com> wrote:
> We have specifically added this logic for the following use case: when
> people want their build system to produce ASan-ified binary, they generally
> just add "-fsanitize=address" to their compile and link flags.
> However, there are cases when we don't want to link in ASan runtime, for
> example:
> 1) we don't link in static ASan runtime into shared objects (that's because
> our runtime works this way).
> 2) we don't link in ASan runtime if -nostdlib is provided. If user is
> passing this flag to linker, he essentially says "I know what I'm doing" and
> is building a hermetic binary, with no extra dependencies.
>   However, ASan runtime *does* bring extra dependencies - it depends on
> libdl, libpthread, libc and librt. Linking it into the binary in this case
> will likely just produce a linker errors due to unresolved symbols.
>
> IMO Android linker invocation in question shouldn't have -nostdlib flag -
> the resulting binary is expected to be dynamically linked to system
> libraries from sysroot.
>
> On Mon, Oct 13, 2014 at 3:46 PM, Hans Wennborg <hans@chromium.org> wrote:
>>
>> So should we change Clang back to adding it to the command line, since
>> it knows the exact location, etc.
>>
>> It seems odd not to add it when -fsanitize=address is specified anyway
>> - that flag seems pretty useless without the runtime?
>>
>> On Mon, Oct 13, 2014 at 3:40 PM, Alexey Samsonov <samsonov@google.com>
>> wrote:
>> > That's kind of tricky - we need both -lasan and -L/path/to/asan/runtime
>> > in
>> > that case. The latter is Clang resource path, somewhere under
>> > third_party/llvm-build/Release+Asserts/lib/clang/..., and it's not nice
>> > to
>> > hardcode it.
>> >
>> > On Mon, Oct 13, 2014 at 3:27 PM, Hans Wennborg <hans@chromium.org>
>> > wrote:
>> >>
>> >> It seems the Android build always uses -nostdlib:
>> >>
>> >>
>> >>
https://code.google.com/p/chromium/codesearch#chromium/src/build/common.gypi&...
>> >>
>> >> Presumably because it wants more control over the link line.
>> >>
>> >> If that's the motivation, maybe they should also explicitly link in
>> >> the asan runtime?
>> >>
>> >> On Mon, Oct 13, 2014 at 3:21 PM, Alexey Samsonov <samsonov@google.com>
>> >> wrote:
>> >> > Yes, looks like my change is the culprit. Linker invocation line I
>> >> > see
>> >> > makes
>> >> > little sense to me: it has "-nostdlib" and a bunch of flags that are
>> >> > supposed to link in system libraries (-ldl, -lc, -lm,
>> >> > -fsanitize=address).
>> >> > That is, I think that Clang behavior is now correct.
>> >> >
>> >> > On Mon, Oct 13, 2014 at 3:02 PM, <hans@chromium.org> wrote:
>> >> >>
>> >> >> samsonov: I think the Android link failure is because of your
>> >> >> r218541.
>> >> >> -nostdlib
>> >> >> is being passed to the linker, and so the link fails:
>> >> >>
>> >> >>
>> >> >>
>> >> >>
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...
>> >> >>
>> >> >> I'm not sure how that's supposed to work though.
>> >> >>
>> >> >> https://codereview.chromium.org/630163005/
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Alexey Samsonov, Mountain View, CA
>> >
>> >
>> >
>> >
>> > --
>> > Alexey Samsonov, Mountain View, CA
>
>
>
>
> --
> Alexey Samsonov, Mountain View, CA

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2014-10-14 08:18:28]

Android build already does things like this to link libgcc:
  <(android_toolchain)/*-gcc -print-libgcc-file-name)

If we want to keep -nostdlib, we should either hardcode path to asan
rt, or obtain it by processing the compiler library search path.

Off the top of my head, I don't see a reason to use -nostdlib. Could
it be a historical artifact?

As to why -nostdlib should disable linking asan runtime, see this
thread: https://code.google.com/p/address-sanitizer/issues/detail?id=344
In short, we want to be able to add -fsanitize=address to
CFLAGS/LINKFLAGS/etc and have it do the right thing (i.e. "enable
asan"). This means it should not link asan runtime when doing partial
linking (-Wl,-r), and the only real clue for that is -nostdlib.


On Tue, Oct 14, 2014 at 3:04 AM, Hans Wennborg <hans@chromium.org> wrote:
> +michaelbai who committed the common.gypi lines adding -nostdlib
> +eugenis who knows the android asan build the best
>
> On Mon, Oct 13, 2014 at 3:57 PM, Alexey Samsonov <samsonov@google.com> wrote:
>> We have specifically added this logic for the following use case: when
>> people want their build system to produce ASan-ified binary, they generally
>> just add "-fsanitize=address" to their compile and link flags.
>> However, there are cases when we don't want to link in ASan runtime, for
>> example:
>> 1) we don't link in static ASan runtime into shared objects (that's because
>> our runtime works this way).
>> 2) we don't link in ASan runtime if -nostdlib is provided. If user is
>> passing this flag to linker, he essentially says "I know what I'm doing" and
>> is building a hermetic binary, with no extra dependencies.
>>   However, ASan runtime *does* bring extra dependencies - it depends on
>> libdl, libpthread, libc and librt. Linking it into the binary in this case
>> will likely just produce a linker errors due to unresolved symbols.
>>
>> IMO Android linker invocation in question shouldn't have -nostdlib flag -
>> the resulting binary is expected to be dynamically linked to system
>> libraries from sysroot.
>>
>> On Mon, Oct 13, 2014 at 3:46 PM, Hans Wennborg <hans@chromium.org> wrote:
>>>
>>> So should we change Clang back to adding it to the command line, since
>>> it knows the exact location, etc.
>>>
>>> It seems odd not to add it when -fsanitize=address is specified anyway
>>> - that flag seems pretty useless without the runtime?
>>>
>>> On Mon, Oct 13, 2014 at 3:40 PM, Alexey Samsonov <samsonov@google.com>
>>> wrote:
>>> > That's kind of tricky - we need both -lasan and -L/path/to/asan/runtime
>>> > in
>>> > that case. The latter is Clang resource path, somewhere under
>>> > third_party/llvm-build/Release+Asserts/lib/clang/..., and it's not nice
>>> > to
>>> > hardcode it.
>>> >
>>> > On Mon, Oct 13, 2014 at 3:27 PM, Hans Wennborg <hans@chromium.org>
>>> > wrote:
>>> >>
>>> >> It seems the Android build always uses -nostdlib:
>>> >>
>>> >>
>>> >>
https://code.google.com/p/chromium/codesearch#chromium/src/build/common.gypi&...
>>> >>
>>> >> Presumably because it wants more control over the link line.
>>> >>
>>> >> If that's the motivation, maybe they should also explicitly link in
>>> >> the asan runtime?
>>> >>
>>> >> On Mon, Oct 13, 2014 at 3:21 PM, Alexey Samsonov <samsonov@google.com>
>>> >> wrote:
>>> >> > Yes, looks like my change is the culprit. Linker invocation line I
>>> >> > see
>>> >> > makes
>>> >> > little sense to me: it has "-nostdlib" and a bunch of flags that are
>>> >> > supposed to link in system libraries (-ldl, -lc, -lm,
>>> >> > -fsanitize=address).
>>> >> > That is, I think that Clang behavior is now correct.
>>> >> >
>>> >> > On Mon, Oct 13, 2014 at 3:02 PM, <hans@chromium.org> wrote:
>>> >> >>
>>> >> >> samsonov: I think the Android link failure is because of your
>>> >> >> r218541.
>>> >> >> -nostdlib
>>> >> >> is being passed to the linker, and so the link fails:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...
>>> >> >>
>>> >> >> I'm not sure how that's supposed to work though.
>>> >> >>
>>> >> >> https://codereview.chromium.org/630163005/
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Alexey Samsonov, Mountain View, CA
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Alexey Samsonov, Mountain View, CA
>>
>>
>>
>>
>> --
>> Alexey Samsonov, Mountain View, CA

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[hans, 2014-10-14 17:59:45]

I've filed crbug.com/423429 to figure out if we can drop -nostdblib from the
Android build.

To unblock the roll in the meantime, I think we should add the runtime to the
link line manually. eugenis, can you take a look the latest diff?

[Evgeniy Stepanov, 2014-10-15 02:29:39]

On 2014/10/14 17:59:45, hans wrote:
> I've filed crbug.com/423429 to figure out if we can drop -nostdblib from the
> Android build.
> 
> To unblock the roll in the meantime, I think we should add the runtime to the
> link line manually. eugenis, can you take a look the latest diff?

It's quite ugly, but I guess it would work until we decide what to do with
-nostdlib.

[hans, 2014-10-15 16:04:08]

The CQ bit was checked by hans@chromium.org

[commit-bot: I haz the power, 2014-10-15 16:05:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/630163005/460001

[commit-bot: I haz the power, 2014-10-15 16:12:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-10-15 16:12:51]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[hans, 2014-10-15 19:53:30]

The CQ bit was checked by hans@chromium.org

[commit-bot: I haz the power, 2014-10-15 19:54:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/630163005/460001

[commit-bot: I haz the power, 2014-10-15 20:03:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-10-15 20:03:25]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[hans, 2014-10-15 21:17:08]

The CQ bit was checked by hans@chromium.org

[commit-bot: I haz the power, 2014-10-15 21:19:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/630163005/460001

[commit-bot: I haz the power, 2014-10-15 21:20:24]

Committed patchset #5 (id:460001)

[commit-bot: I haz the power, 2014-10-15 21:21:07]

Patchset 5 (id:??) landed as
https://crrev.com/51709a2ce53da80b7814b9244fb874e185e50566
Cr-Commit-Position: refs/heads/master@{#299766}