Android: Enable C99 mode instead of C89 (default).

Android: Enable C99 mode instead of C89 (default).

BUG=webrtc:4960
TESTED=Built locally using GYP and GN for Android.
R=andrew@webrtc.org, brettw@chromium.org

Committed: https://crrev.com/7bff85c2bc741102b41b259752269f9ecd398d68
Cr-Commit-Position: refs/heads/master@{#9937}

[kjellander_webrtc, 2015-09-07 12:18:18]

Patchset #3 (id:40001) has been deleted

[kjellander_webrtc, 2015-09-07 12:19:33]

kjellander@webrtc.org changed reviewers:
+ pkasting@chromium.org

[kjellander_webrtc, 2015-09-07 12:19:34]

pkasting: Do you know what's wrong with 	webrtc/build/common.gypi in PS#1 or 2?
Ignore GN since it wasn't valid until PS#3.

[Peter Kasting, 2015-09-07 19:06:59]

On 2015/09/07 12:19:34, kjellander (webrtc) wrote:
> pkasting: Do you know what's wrong with 	webrtc/build/common.gypi in PS#1 or
2?
> Ignore GN since it wasn't valid until PS#3.

It seems like you have to pass this only for C files and not C++.  I assume
there's some way of doing that but you'd have to contact the gyp/gn people to be
sure.  Maybe start with brettw.

[kjellander_webrtc, 2015-09-10 07:24:50]

On 2015/09/07 19:06:59, Peter Kasting wrote:
> On 2015/09/07 12:19:34, kjellander (webrtc) wrote:
> > pkasting: Do you know what's wrong with 	webrtc/build/common.gypi in PS#1 or
> 2?
> > Ignore GN since it wasn't valid until PS#3.
> 
> It seems like you have to pass this only for C files and not C++.  I assume
> there's some way of doing that but you'd have to contact the gyp/gn people to
be
> sure.  Maybe start with brettw.

I'll just check which of our projects that have .c files (they're not that many)
and add the flag to them instead of globally. Stay tuned.

[kjellander_webrtc, 2015-09-10 13:37:09]

kjellander@webrtc.org changed reviewers:
+ brettw@chromium.org

[kjellander_webrtc, 2015-09-10 13:38:28]

On 2015/09/10 07:24:50, kjellander (webrtc) wrote:
> On 2015/09/07 19:06:59, Peter Kasting wrote:
> > On 2015/09/07 12:19:34, kjellander (webrtc) wrote:
> > > pkasting: Do you know what's wrong with 	webrtc/build/common.gypi in PS#1
or
> > 2?
> > > Ignore GN since it wasn't valid until PS#3.
> > 
> > It seems like you have to pass this only for C files and not C++.  I assume
> > there's some way of doing that but you'd have to contact the gyp/gn people
to
> be
> > sure.  Maybe start with brettw.
> 
> I'll just check which of our projects that have .c files (they're not that
many)
> and add the flag to them instead of globally. Stay tuned.

+brettw

Even for the minimal test in PS#5 it fails since it's using g++ even if it's
compiling a .c file.
Brett: is there a way to get GYP/GN to use gcc instead of g++, or how do you
suggest we solve this problem?

[brettw, 2015-09-10 15:49:00]

It should be using gcc for .c files. The toolchain should define separate "cc"
and "cxx" tools. Do you guys have your own toolchain definition?

[kjellander_webrtc, 2015-09-11 09:15:34]

On 2015/09/10 15:49:00, brettw wrote:
> It should be using gcc for .c files. The toolchain should define separate "cc"
> and "cxx" tools. Do you guys have your own toolchain definition?

I'm not sure what we could have that's different. Since the way we use the build
toolchain is setup so it imitates being inside a Chromium checkout, I would
assume everything is identical to Chromium.

Detailed explanation: we use symlinks from the WebRTC checkout into a chromium
checkout, like this:
chromium/src <-- Chromium checkout, pinned to a revision in our DEPS
build -> chromium/src/build (symlink)
tools/gn -> chromium/src/tools/gn (symlink)
.. and so on.

I believe the only files that defines anything specific to our builds are:
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/BUILD.gn
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/build/webrt...
but I don't know if that falls into the definition of "have your own toolchain
definition" ?

[brettw, 2015-09-11 15:53:09]

On 2015/09/11 09:15:34, kjellander (webrtc) wrote:
> On 2015/09/10 15:49:00, brettw wrote:
> > It should be using gcc for .c files. The toolchain should define separate
"cc"
> > and "cxx" tools. Do you guys have your own toolchain definition?
> 
> I'm not sure what we could have that's different. Since the way we use the
build
> toolchain is setup so it imitates being inside a Chromium checkout, I would
> assume everything is identical to Chromium.
> 
> Detailed explanation: we use symlinks from the WebRTC checkout into a chromium
> checkout, like this:
> chromium/src <-- Chromium checkout, pinned to a revision in our DEPS
> build -> chromium/src/build (symlink)
> tools/gn -> chromium/src/tools/gn (symlink)
> .. and so on.
> 
> I believe the only files that defines anything specific to our builds are:
> https://chromium.googlesource.com/external/webrtc/+/master/webrtc/BUILD.gn
>
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/build/webrt...
> but I don't know if that falls into the definition of "have your own toolchain
> definition" ?

Can you check the ninja files to see whether it's using the CC or CXX compiler?

[kjellander_webrtc, 2015-09-14 15:16:57]

On 2015/09/11 15:53:09, brettw wrote:
> On 2015/09/11 09:15:34, kjellander (webrtc) wrote:
> > On 2015/09/10 15:49:00, brettw wrote:
> > > It should be using gcc for .c files. The toolchain should define separate
> "cc"
> > > and "cxx" tools. Do you guys have your own toolchain definition?
> > 
> > I'm not sure what we could have that's different. Since the way we use the
> build
> > toolchain is setup so it imitates being inside a Chromium checkout, I would
> > assume everything is identical to Chromium.
> > 
> > Detailed explanation: we use symlinks from the WebRTC checkout into a
chromium
> > checkout, like this:
> > chromium/src <-- Chromium checkout, pinned to a revision in our DEPS
> > build -> chromium/src/build (symlink)
> > tools/gn -> chromium/src/tools/gn (symlink)
> > .. and so on.
> > 
> > I believe the only files that defines anything specific to our builds are:
> > https://chromium.googlesource.com/external/webrtc/+/master/webrtc/BUILD.gn
> >
>
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/build/webrt...
> > but I don't know if that falls into the definition of "have your own
toolchain
> > definition" ?
> 
> Can you check the ninja files to see whether it's using the CC or CXX
compiler?

Sure. It looks like it's should be using gcc instead of g++. I wonder why it's
not:

$ head -n4 out/Debug/build.ninja 
cc = $
   
/ssd/webrtc/src/third_party/android_tools/ndk//toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc
cxx = $
   
/ssd/webrtc/src/third_party/android_tools/ndk//toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++



 $ grep nearest_neighbor out/Debug/obj/webrtc/modules/ilbc.ninja
build obj/webrtc/modules/audio_coding/codecs/ilbc/ilbc.nearest_neighbor.o: $
    cc ../../webrtc/modules/audio_coding/codecs/ilbc/nearest_neighbor.c
    obj/webrtc/modules/audio_coding/codecs/ilbc/ilbc.nearest_neighbor.o $



 $ ninja -C out/Debug ilbc
ninja: Entering directory `out/Debug'
[1/2] CXX obj/webrtc/modules/audio_coding/codecs/ilbc/ilbc.audio_encoder_ilbc.o
FAILED:
/ssd/webrtc/src/third_party/android_tools/ndk//toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
-MMD -MF obj/webrtc/modules/audio_coding/codecs/ilbc/ilbc.audio_encoder_ilbc.o.d
-DV8_DEPRECATION_WARNINGS -DCLD_VERSION=2 -DEXPAT_RELATIVE_PATH
-DWEBRTC_ARCH_ARM -DWEBRTC_ARCH_ARM_V7 -DWEBRTC_DETECT_NEON -DWEBRTC_POSIX
-DWEBRTC_LINUX -DWEBRTC_ANDROID -DWEBRTC_INCLUDE_INTERNAL_AUDIO_DEVICE
-D_FILE_OFFSET_BITS=64 -DNO_TCMALLOC -DDISABLE_NACL -DCHROMIUM_BUILD
-DCR_CLANG_REVISION=245965-1 -DUSE_LIBJPEG_TURBO=1 -DENABLE_WEBRTC=1
-DENABLE_MEDIA_ROUTER=1 -DUSE_PROPRIETARY_CODECS -DENABLE_BROWSER_CDMS
-DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS
-DSYSTEM_NATIVELY_SIGNALS_MEMORY_PRESSURE -DDONT_EMBED_BUILD_METADATA
-DFIELDTRIAL_TESTING_ENABLED -DENABLE_AUTOFILL_DIALOG=1 -DENABLE_PRINTING=1
-DENABLE_BASIC_PRINTING=1 -DENABLE_SPELLCHECK=1 -DUSE_BROWSER_SPELLCHECKER=1
-DENABLE_SUPERVISED_USERS=1 -DVIDEO_HOLE=1 -DV8_USE_EXTERNAL_STARTUP_DATA
-DENABLE_WEBVR -DMOBILE_SAFE_BROWSING -DSAFE_BROWSING_SERVICE -DUSE_LIBPCI=1
-DUSE_OPENSSL=1 -DUSE_OPENSSL_CERTS=1 -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -DANDROID -D__GNU_SOURCE=1 '-DCHROME_BUILD_ID=""'
-DHAVE_SYS_UIO_H -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1
-D_DEBUG -Igen -I../.. -I../../webrtc/modules/audio_coding/codecs/ilbc/interface
-I../../webrtc -I../../webrtc/common_audio/resampler/include
-I../../webrtc/common_audio/signal_processing/include
-I../../webrtc/common_audio/vad/include -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wno-strict-overflow -fno-builtin-cos
-fno-builtin-sin -fno-builtin-cosf -fno-builtin-sinf -std=gnu99
-fstack-protector --param=ssp-buffer-size=4 -Werror -fno-strict-aliasing -Wall
-Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe
-fPIC -Wno-unused-local-typedefs -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wno-strict-overflow -fno-builtin-cos
-fno-builtin-sin -fno-builtin-cosf -fno-builtin-sinf -std=gnu99 -Wextra
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-strict-overflow
-fno-builtin-cos -fno-builtin-sin -fno-builtin-cosf -fno-builtin-sinf -std=gnu99
-Wextra -Wno-unused-parameter -Wno-missing-field-initializers
-Wno-strict-overflow -fno-builtin-cos -fno-builtin-sin -fno-builtin-cosf
-fno-builtin-sinf -std=gnu99 -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wno-strict-overflow -fno-builtin-cos
-fno-builtin-sin -fno-builtin-cosf -fno-builtin-sinf -std=gnu99 -march=armv7-a
-mtune=generic-armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -fno-tree-sra
-fno-caller-saves -Wno-psabi -mthumb-interwork -ffunction-sections
-funwind-tables -g -fstack-protector -fno-short-enums -finline-limit=64
--sysroot=../../third_party/android_tools/ndk//platforms/android-16/arch-arm
-isystem../../third_party/android_tools/ndk//sources/cxx-stl/llvm-libc++/libcxx/include
-isystem../../third_party/android_tools/ndk//sources/cxx-stl/llvm-libc++abi/libcxxabi/include
-isystem../../third_party/android_tools/ndk//sources/android/support/include -Os
-g -fdata-sections -ffunction-sections -fomit-frame-pointer -funwind-tables
-Wnon-virtual-dtor -Woverloaded-virtual -fno-exceptions -fno-rtti
-fno-threadsafe-statics -fvisibility-inlines-hidden -Wsign-compare
-Wnon-virtual-dtor -Woverloaded-virtual -Wnon-virtual-dtor -Woverloaded-virtual
-Wnon-virtual-dtor -Woverloaded-virtual -Wnon-virtual-dtor -Woverloaded-virtual
-Wno-abi -std=gnu++11 -Wno-narrowing -Wno-literal-suffix  -c
../../webrtc/modules/audio_coding/codecs/ilbc/audio_encoder_ilbc.cc -o
obj/webrtc/modules/audio_coding/codecs/ilbc/ilbc.audio_encoder_ilbc.o
cc1plus: error: command line option '-std=gnu99' is valid for C/ObjC but not for
C++ [-Werror]
cc1plus: error: command line option '-std=gnu99' is valid for C/ObjC but not for
C++ [-Werror]
cc1plus: error: command line option '-std=gnu99' is valid for C/ObjC but not for
C++ [-Werror]
cc1plus: error: command line option '-std=gnu99' is valid for C/ObjC but not for
C++ [-Werror]
cc1plus: error: command line option '-std=gnu99' is valid for C/ObjC but not for
C++ [-Werror]
cc1plus: all warnings being treated as errors
ninja: build stopped: subcommand failed.

[kjellander_webrtc, 2015-09-14 15:19:33]

On 2015/09/14 15:16:57, kjellander (webrtc) wrote:
> On 2015/09/11 15:53:09, brettw wrote:
> > On 2015/09/11 09:15:34, kjellander (webrtc) wrote:
> > > On 2015/09/10 15:49:00, brettw wrote:
> > > > It should be using gcc for .c files. The toolchain should define
separate
> > "cc"
> > > > and "cxx" tools. Do you guys have your own toolchain definition?
> > > 
> > > I'm not sure what we could have that's different. Since the way we use the
> > build
> > > toolchain is setup so it imitates being inside a Chromium checkout, I
would
> > > assume everything is identical to Chromium.
> > > 
> > > Detailed explanation: we use symlinks from the WebRTC checkout into a
> chromium
> > > checkout, like this:
> > > chromium/src <-- Chromium checkout, pinned to a revision in our DEPS
> > > build -> chromium/src/build (symlink)
> > > tools/gn -> chromium/src/tools/gn (symlink)
> > > .. and so on.
> > > 
> > > I believe the only files that defines anything specific to our builds are:
> > > https://chromium.googlesource.com/external/webrtc/+/master/webrtc/BUILD.gn
> > >
> >
>
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/build/webrt...
> > > but I don't know if that falls into the definition of "have your own
> toolchain
> > > definition" ?
> > 
> > Can you check the ninja files to see whether it's using the CC or CXX
> compiler?
> 
> Sure. It looks like it's should be using gcc instead of g++. I wonder why it's
> not:
> 
> $ head -n4 out/Debug/build.ninja 
> cc = $
>    
>
/ssd/webrtc/src/third_party/android_tools/ndk//toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc
> cxx = $
>    
>
/ssd/webrtc/src/third_party/android_tools/ndk//toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
> 
> 
> 
>  $ grep nearest_neighbor out/Debug/obj/webrtc/modules/ilbc.ninja
> build obj/webrtc/modules/audio_coding/codecs/ilbc/ilbc.nearest_neighbor.o: $
>     cc ../../webrtc/modules/audio_coding/codecs/ilbc/nearest_neighbor.c
>     obj/webrtc/modules/audio_coding/codecs/ilbc/ilbc.nearest_neighbor.o $
> 
> 
> 
>  $ ninja -C out/Debug ilbc
> ninja: Entering directory `out/Debug'
> [1/2] CXX
obj/webrtc/modules/audio_coding/codecs/ilbc/ilbc.audio_encoder_ilbc.o
> FAILED:
>
/ssd/webrtc/src/third_party/android_tools/ndk//toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
> -MMD -MF
obj/webrtc/modules/audio_coding/codecs/ilbc/ilbc.audio_encoder_ilbc.o.d
> -DV8_DEPRECATION_WARNINGS -DCLD_VERSION=2 -DEXPAT_RELATIVE_PATH
> -DWEBRTC_ARCH_ARM -DWEBRTC_ARCH_ARM_V7 -DWEBRTC_DETECT_NEON -DWEBRTC_POSIX
> -DWEBRTC_LINUX -DWEBRTC_ANDROID -DWEBRTC_INCLUDE_INTERNAL_AUDIO_DEVICE
> -D_FILE_OFFSET_BITS=64 -DNO_TCMALLOC -DDISABLE_NACL -DCHROMIUM_BUILD
> -DCR_CLANG_REVISION=245965-1 -DUSE_LIBJPEG_TURBO=1 -DENABLE_WEBRTC=1
> -DENABLE_MEDIA_ROUTER=1 -DUSE_PROPRIETARY_CODECS -DENABLE_BROWSER_CDMS
> -DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS
> -DSYSTEM_NATIVELY_SIGNALS_MEMORY_PRESSURE -DDONT_EMBED_BUILD_METADATA
> -DFIELDTRIAL_TESTING_ENABLED -DENABLE_AUTOFILL_DIALOG=1 -DENABLE_PRINTING=1
> -DENABLE_BASIC_PRINTING=1 -DENABLE_SPELLCHECK=1 -DUSE_BROWSER_SPELLCHECKER=1
> -DENABLE_SUPERVISED_USERS=1 -DVIDEO_HOLE=1 -DV8_USE_EXTERNAL_STARTUP_DATA
> -DENABLE_WEBVR -DMOBILE_SAFE_BROWSING -DSAFE_BROWSING_SERVICE -DUSE_LIBPCI=1
> -DUSE_OPENSSL=1 -DUSE_OPENSSL_CERTS=1 -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -DANDROID -D__GNU_SOURCE=1 '-DCHROME_BUILD_ID=""'
> -DHAVE_SYS_UIO_H -DDYNAMIC_ANNOTATIONS_ENABLED=1
-DWTF_USE_DYNAMIC_ANNOTATIONS=1
> -D_DEBUG -Igen -I../..
-I../../webrtc/modules/audio_coding/codecs/ilbc/interface
> -I../../webrtc -I../../webrtc/common_audio/resampler/include
> -I../../webrtc/common_audio/signal_processing/include
> -I../../webrtc/common_audio/vad/include -Wextra -Wno-unused-parameter
> -Wno-missing-field-initializers -Wno-strict-overflow -fno-builtin-cos
> -fno-builtin-sin -fno-builtin-cosf -fno-builtin-sinf -std=gnu99
> -fstack-protector --param=ssp-buffer-size=4 -Werror -fno-strict-aliasing -Wall
> -Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden
-pipe
> -fPIC -Wno-unused-local-typedefs -Wextra -Wno-unused-parameter
> -Wno-missing-field-initializers -Wno-strict-overflow -fno-builtin-cos
> -fno-builtin-sin -fno-builtin-cosf -fno-builtin-sinf -std=gnu99 -Wextra
> -Wno-unused-parameter -Wno-missing-field-initializers -Wno-strict-overflow
> -fno-builtin-cos -fno-builtin-sin -fno-builtin-cosf -fno-builtin-sinf
-std=gnu99
> -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
> -Wno-strict-overflow -fno-builtin-cos -fno-builtin-sin -fno-builtin-cosf
> -fno-builtin-sinf -std=gnu99 -Wextra -Wno-unused-parameter
> -Wno-missing-field-initializers -Wno-strict-overflow -fno-builtin-cos
> -fno-builtin-sin -fno-builtin-cosf -fno-builtin-sinf -std=gnu99 -march=armv7-a
> -mtune=generic-armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb
-fno-tree-sra
> -fno-caller-saves -Wno-psabi -mthumb-interwork -ffunction-sections
> -funwind-tables -g -fstack-protector -fno-short-enums -finline-limit=64
> --sysroot=../../third_party/android_tools/ndk//platforms/android-16/arch-arm
>
-isystem../../third_party/android_tools/ndk//sources/cxx-stl/llvm-libc++/libcxx/include
>
-isystem../../third_party/android_tools/ndk//sources/cxx-stl/llvm-libc++abi/libcxxabi/include
> -isystem../../third_party/android_tools/ndk//sources/android/support/include
-Os
> -g -fdata-sections -ffunction-sections -fomit-frame-pointer -funwind-tables
> -Wnon-virtual-dtor -Woverloaded-virtual -fno-exceptions -fno-rtti
> -fno-threadsafe-statics -fvisibility-inlines-hidden -Wsign-compare
> -Wnon-virtual-dtor -Woverloaded-virtual -Wnon-virtual-dtor
-Woverloaded-virtual
> -Wnon-virtual-dtor -Woverloaded-virtual -Wnon-virtual-dtor
-Woverloaded-virtual
> -Wno-abi -std=gnu++11 -Wno-narrowing -Wno-literal-suffix  -c
> ../../webrtc/modules/audio_coding/codecs/ilbc/audio_encoder_ilbc.cc -o
> obj/webrtc/modules/audio_coding/codecs/ilbc/ilbc.audio_encoder_ilbc.o
> cc1plus: error: command line option '-std=gnu99' is valid for C/ObjC but not
for
> C++ [-Werror]
> cc1plus: error: command line option '-std=gnu99' is valid for C/ObjC but not
for
> C++ [-Werror]
> cc1plus: error: command line option '-std=gnu99' is valid for C/ObjC but not
for
> C++ [-Werror]
> cc1plus: error: command line option '-std=gnu99' is valid for C/ObjC but not
for
> C++ [-Werror]
> cc1plus: error: command line option '-std=gnu99' is valid for C/ObjC but not
for
> C++ [-Werror]
> cc1plus: all warnings being treated as errors
> ninja: build stopped: subcommand failed.

Oh, I see the error comes from that audio_encoder_ilbc.cc is being compiled with
g++ and the -std=gnu99 flag now. Is g++ incorrectly picking up cflags too,
instead of just cflags_cc?

[Andrew MacDonald, 2015-09-14 16:09:24]

On 2015/09/14 15:19:33, kjellander (webrtc) wrote:
> Oh, I see the error comes from that audio_encoder_ilbc.cc is being compiled
with
> g++ and the -std=gnu99 flag now. Is g++ incorrectly picking up cflags too,
> instead of just cflags_cc?

I think cflags applies to both C and C++ files. Does cflags_c work?

[kjellander_webrtc, 2015-09-14 17:04:00]

kjellander@webrtc.org changed reviewers:
+ andrew@webrtc.org

[kjellander_webrtc, 2015-09-14 17:18:25]

On 2015/09/14 16:09:24, Andrew MacDonald wrote:
> On 2015/09/14 15:19:33, kjellander (webrtc) wrote:
> > Oh, I see the error comes from that audio_encoder_ilbc.cc is being compiled
> with
> > g++ and the -std=gnu99 flag now. Is g++ incorrectly picking up cflags too,
> > instead of just cflags_cc?
> 
> I think cflags applies to both C and C++ files. Does cflags_c work?

Thanks Andrew, that was it! 
It works to apply on a global level and with -std=c99 as well! Please review.

[brettw, 2015-09-14 18:05:18]

lgtm

[Andrew MacDonald, 2015-09-14 18:06:33]

lgtm

[kjellander_webrtc, 2015-09-14 18:16:04]

The CQ bit was checked by kjellander@webrtc.org

[commit-bot: I haz the power, 2015-09-14 18:16:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1321193003/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1321193003/140001

[commit-bot: I haz the power, 2015-09-14 20:16:37]

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

[commit-bot: I haz the power, 2015-09-14 20:16:38]

Try jobs failed on following builders:
  android on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[kjellander_webrtc, 2015-09-15 06:16:17]

Committed patchset #7 (id:140001) manually as
7bff85c2bc741102b41b259752269f9ecd398d68 (presubmit successful).

[commit-bot: I haz the power, 2015-09-15 06:16:18]

Patchset 7 (id:??) landed as
https://crrev.com/7bff85c2bc741102b41b259752269f9ecd398d68
Cr-Commit-Position: refs/heads/master@{#9937}

[kjellander_webrtc, 2015-09-21 07:31:05]

On 2015/09/15 06:16:18, commit-bot: I haz the power wrote:
> Patchset 7 (id:??) landed as
> https://crrev.com/7bff85c2bc741102b41b259752269f9ecd398d68
> Cr-Commit-Position: refs/heads/master@{#9937}

So it turns out this broke Chrome OS bots and the code change was reverted here
https://codereview.webrtc.org/1354163002/
Any suggestions on how to proceed? Revert this entirely or talk to Chrome OS
team about if they can update their toolchain configurations?

[kjellander_webrtc, 2015-09-21 14:53:09]

On 2015/09/21 07:31:05, kjellander (webrtc) wrote:
> On 2015/09/15 06:16:18, commit-bot: I haz the power wrote:
> > Patchset 7 (id:??) landed as
> > https://crrev.com/7bff85c2bc741102b41b259752269f9ecd398d68
> > Cr-Commit-Position: refs/heads/master@{#9937}
> 
> So it turns out this broke Chrome OS bots and the code change was reverted
here
> https://codereview.webrtc.org/1354163002/
> Any suggestions on how to proceed? Revert this entirely or talk to Chrome OS
> team about if they can update their toolchain configurations?

I reverted the rest of this CL for now in
https://codereview.webrtc.org/1343263004/. 
I think the only viable approach moving forward (considering customers
downstream) is to refactor targets containing .c files into their own target,
and add the flag explicitly there only.

[Andrew MacDonald, 2015-09-21 19:13:15]

On 2015/09/21 14:53:09, kjellander (webrtc) wrote:
> I reverted the rest of this CL for now in
> https://codereview.webrtc.org/1343263004/. 
> I think the only viable approach moving forward (considering customers
> downstream) is to refactor targets containing .c files into their own target,
> and add the flag explicitly there only.

Good to know.