956631 - [tarako][build]create "tarako" build

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[thomas tsai]

1. Get code and build
git clone https://github.com/sprd-ffos/B2G.git -b sprd
./config.sh sp6821a_gonk4.0
./build.sh

2. update u-boot.bin
adb reboot bootloader
fastboot flash 2ndbl u-boot.bin

3. switch to root under adb shell
adb root

Comment 1

[Kai-Zhen Li [:seinlin][:kli]]

Need to assign install path for "flash.sh gaia".

GAIA_INSTALL_PARENT=/data/local ./flash.sh gaia

Comment 2

[[:fabrice] Fabrice Desré]

(In reply to Kai-Zhen Li from comment #1)
> Need to assign install path for "flash.sh gaia".
> 
> GAIA_INSTALL_PARENT=/data/local ./flash.sh gaia

We really need to get apps installed in /system for production builds though.

Comment 3

[James Zhang (Spreadtrum)]

Thomas, please check new tarako pac on my FTP, support fastboot.

Comment 4

[Jonathan Griffin (:jgriffin)]

We'll need VARIANT=eng builds for automation; I guess someone will want VARIANT=user builds as well, but am not sure.

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

Attachment: (dubious?) flash.sh patch

I was able to flash the gonk on my tarako device by applying this patch then doing:

  ./config.sh sp6821a_gonk4.0
  ./build.sh
  ./flash.sh

The patch is against the sprd branch in:

  https://github.com/sprd-ffos/B2G.git

Kai-Zhen, does this look reasonable?

Comment 6

[Hubert Figuiere [:hub]]

There are error about failed patches

Also there are a few patches that I needed to apply to be able to build. Will attach them.

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

Hub, can you also say what steps you followed?  Using thre steps in comment 5 I did not run into any build errors.

Comment 8

[Hubert Figuiere [:hub]]

Same steps. One of the build breakage is the good old bug 854389 that came because sprd use their own fork based on the broken Google code.

Comment 9

[Hubert Figuiere [:hub]]

Attachment: frameworks/base patch to fix

This fix the frameworks/base build. See 854389

Comment 10

[Hubert Figuiere [:hub]]

Attachment: sprd.diff

Comment 11

[Hubert Figuiere [:hub]]

Comment on attachment 8370292 [details] [diff] [review]
sprd.diff

device/sprd fails because of a broken Android.mk

Comment 12

[thomas tsai]

James: please update the patch, sprd.diff. It's a half-width font, not a full-width font for ":".

Comment 13

[Hubert Figuiere [:hub]]

Also why is it that after building, gaia has a large number of uncommitted changes?

Can't we just use git branches instead?

Comment 14

[[:fabrice] Fabrice Desré]

This repo is temporary while the device config is upstreamed to the main b2g repo. No need to lose time on details here.

Comment 15

[James Zhang (Spreadtrum)]

xinhe will take it.

Comment 16

[James Zhang (Spreadtrum)]

(In reply to Hubert Figuiere [:hub] from comment #9)
> Created attachment 8370291 [details] [diff] [review]
> frameworks/base patch to fix
> 
> This fix the frameworks/base build. See 854389

OK, I'll cherry-pick this commit.


commit 579c2b4dc12543f53cf3c885b4a8525cfe4a533d
Author: Al Sutton <[e-mail]>
Date:   Sun Feb 19 08:31:19 2012 +0000

    Xcode 4.3 compatibility checkin
    
    The update compiler in Xcode 4.3 (and 4.4) requires lookups into dependant
    bases of class templates to be qualified. This checkin fixes the issues
    raised by the compiler by implementing the this-> recommendation from
    the llvm page at http://clang.llvm.org/compatibility.html#dep_lookup_bases
    
    Signed-off-by: Al Sutton <[e-mail]>

diff --git a/include/utils/KeyedVector.h b/include/utils/KeyedVector.h
index 6bcdea4..65165a2 100644
--- a/include/utils/KeyedVector.h
+++ b/include/utils/KeyedVector.h
@@ -122,7 +122,7 @@ ssize_t KeyedVector<KEY,VALUE>::indexOfKey(const KEY& key) const {
 
 template<typename KEY, typename VALUE> inline
 const VALUE& KeyedVector<KEY,VALUE>::valueFor(const KEY& key) const {
-    ssize_t i = indexOfKey(key);
+    ssize_t i = this->indexOfKey(key);
     assert(i>=0);
     return mVector.itemAt(i).value;
 }
@@ -139,7 +139,7 @@ const KEY& KeyedVector<KEY,VALUE>::keyAt(size_t index) const {
 
 template<typename KEY, typename VALUE> inline
 VALUE& KeyedVector<KEY,VALUE>::editValueFor(const KEY& key) {
-    ssize_t i = indexOfKey(key);
+    ssize_t i = this->indexOfKey(key);
     assert(i>=0);
     return mVector.editItemAt(i).value;
 }
@@ -190,7 +190,7 @@ DefaultKeyedVector<KEY,VALUE>::DefaultKeyedVector(const VALUE& defValue)
 
 template<typename KEY, typename VALUE> inline
 const VALUE& DefaultKeyedVector<KEY,VALUE>::valueFor(const KEY& key) const {
-    ssize_t i = indexOfKey(key);
+    ssize_t i = this->indexOfKey(key);
     return i >= 0 ? KeyedVector<KEY,VALUE>::valueAt(i) : mDefault;
 }

Comment 17

[Hubert Figuiere [:hub]]

(In reply to James Zhang from comment #16)
> (In reply to Hubert Figuiere [:hub] from comment #9)
> > Created attachment 8370291 [details] [diff] [review]
> > frameworks/base patch to fix
> > 
> > This fix the frameworks/base build. See 854389
> 
> OK, I'll cherry-pick this commit.
> 

Thanks !

Comment 18

[James Zhang (Spreadtrum)]

Fixed on my side, please repo sync the code.

Comment 19

[Joe Cheng [:jcheng] (please needinfo)]

hi Aki, i believe we have tarako build internally. do you mind confirming? Thanks

Comment 20

[Aki Sasaki (not active)]

(In reply to Joe Cheng [:jcheng] from comment #19)
> hi Aki, i believe we have tarako build internally. do you mind confirming?
> Thanks

RelEng doesn't have any instructions on how to build Tarako.
This bug appeared to be a request for RelEng to create an automated Tarako build, but then it became a dev bug.

Comment 21

[Kai-Zhen Li [:seinlin][:kli]]

Comment on attachment 8369814 [details] [diff] [review]
(dubious?) flash.sh patch

Review of attachment 8369814 [details] [diff] [review]:
-----------------------------------------------------------------

I think it's reasonable. I use "sp6821"* in my local flash.sh.

Comment 22

[James Zhang (Spreadtrum)]

Fix frameworks and device/sprd on my side.

Comment 24

[Askeing Yen[:askeing][:fyen]]

Reopen it due to this issue seems like be a request to generate the Tarako pvt builds.

Comment 25

[Vincent Liu[:vliu]]

For the developers who wants to clone tarako build, please following the below steps.

1. git clone https://github.com/mozilla-b2g/B2G
2. cd B2G
3. BRANCH=v1.3t ./config.sh tarako
4. git clone [e-mail]:Seinlin/tarako-patches.git -b v1.3t patches
5. ./build.sh -j1

Comment 26

[cmtalbert]

James, will this repo have the patch you referenced on bug 975232 to fix the USB issues?  I don't see it in the commit history on github, so I am curious.

Thanks

Comment 27

[ying.xu]

(In reply to Clint Talbert ( :ctalbert ) from comment #26)
> James, will this repo have the patch you referenced on bug 975232 to fix the
> USB issues?  I don't see it in the commit history on github, so I am curious.
> 
> Thanks

yes, There is some delay of syncing the code from sprd internal server to public server.

Comment 28

[James Zhang (Spreadtrum)]

(In reply to Clint Talbert ( :ctalbert ) from comment #26)
> James, will this repo have the patch you referenced on bug 975232 to fix the
> USB issues?  I don't see it in the commit history on github, so I am curious.
> 
> Thanks

repo sync
cd device/sprd
git show 27a4b15ae8c526f538409504acb86643c0cd4daa

commit 27a4b15ae8c526f538409504acb86643c0cd4daa
Author: lianxiang.zhou <[e-mail]>
Date:   Mon Mar 3 15:25:24 2014 +0800

    Bug #275374 usb tethering can not work
    
    [bug number  ] 275374
    [root cause  ]
    [changes     ]
    [side effects]
    [reviewers   ]
    
    Change-Id: Id490f6450d6f755e94b97b1e5adfa5c1e722af34

Comment 29

[cmtalbert]

Thanks James, we are testing this patch now, and so far it is looking good. Many thanks!

Comment 30

[Joe Cheng [:jcheng] (please needinfo)]

Clint, wonder if we have all the information we need to generate tarako 1.3T PVT build? thanks

Comment 31

[ying.xu]

I think you can do it.

(In reply to Joe Cheng [:jcheng] from comment #30)
> Clint, wonder if we have all the information we need to generate tarako 1.3T
> PVT build? thanks

Comment 32

[Joe Cheng [:jcheng] (please needinfo)]

meant to ni? Clint, sorry about this

Comment 33

[cmtalbert]

So, yes, I think I have all the information. The builds are working for me now.

I'll move this to catlee at this point.

Catlee: steps:
export BRANCH=v1.3t
./config.sh tarako
./build.sh -j1

That's what we want for the per-change pvt builds (per change to 1.3t branch). From what I understand, we only want to build and test the fixes landed directly in the 1.3t branch, and without any other patch queues in place. We need this very very soon.

Comment 34

[Jordan Lund (:jlund)]

Attachment: 956631_tarako_support-bbotcustom-130311.diff

adds support for normalizing 'tarako'

Comment 35

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: [buildbot-configs] Add tarako builds

Adds a b2g_mozilla-b2g28_v1_3t_tarako_eng_dep builder, Hg Poller for releases/mozilla-b2g28_v1_3t, and scheduler to hook them together.

Comment 36

[Jordan Lund (:jlund)]

Attachment: 956631_tarako_support-bbotcustom-130311-2.diff

same as before but removes buri-limited-memory

Comment 37

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 8389493 [details] [diff] [review]
956631_tarako_support-bbotcustom-130311-2.diff

lgtm, buri-limited-memory was a tarako stopgap that never got off the ground.

Comment 38

[Ryan VanderMeulen [:RyanVM]]

Do we need to start running the Bumper Bot on 1.3t now that we're doing per-push builds and smoketesting?

Comment 39

[Chris AtLee [:catlee]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #38)
> Do we need to start running the Bumper Bot on 1.3t now that we're doing
> per-push builds and smoketesting?

Yup, working on the patches for that right now.

Comment 40

[Jordan Lund (:jlund)]

Comment on attachment 8389493 [details] [diff] [review]
956631_tarako_support-bbotcustom-130311-2.diff

pushed to default: https://hg.mozilla.org/build/buildbotcustom/rev/ff1839766411

Comment 41

[John Hopkins (:jhopkins)]

in production

Comment 42

[Chris AtLee [:catlee]]

Attachment: in-tree configs for tarako

sources.xml will be generated by the bumper

Comment 43

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 8389490 [details] [diff] [review]
[buildbot-configs] Add tarako builds

https://hg.mozilla.org/build/buildbot-configs/rev/b6dd6f92789e

Comment 44

[John Hopkins (:jhopkins)]

in production

Comment 45

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: [tools] buildapi support for branch

Comment 46

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8389998 [details] [diff] [review]
in-tree configs for tarako

I went ahead and pushed this to the 1.3t branch. I haven't pushed it to trunk.
https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/f83c7b48d9cd

Comment 47

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 8390121 [details] [diff] [review]
[tools] buildapi support for branch

https://hg.mozilla.org/build/tools/rev/e2a885bc5e05 + buildapi pulls it automatically.

Comment 48

[Chris AtLee [:catlee]]

Attachment: b2g bumper config for v1.3t

Comment 49

[Hal Wine [:hwine] use NI!]

Comment on attachment 8391260 [details] [diff] [review]
b2g bumper config for v1.3t

Review of attachment 8391260 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm compared to v1.3 - this is new to me code, so if really unsure may also want aki to look

Comment 50

[Chris AtLee [:catlee]]

Attachment: run bumper on v1.3t

Comment 51

[Justin Wood (:Callek)]

Comment on attachment 8391313 [details] [diff] [review]
run bumper on v1.3t

Review of attachment 8391313 [details] [diff] [review]:
-----------------------------------------------------------------

be sure we get nagios updated to watch this .log as well please.

Comment 52

[Justin Wood (:Callek)]

Comment on attachment 8391313 [details] [diff] [review]
run bumper on v1.3t

In production

Comment 53

[Chris AtLee [:catlee]]

Comment on attachment 8391313 [details] [diff] [review]
run bumper on v1.3t

pushed and deployed to production

Comment 54

[Chris AtLee [:catlee]]

Attachment: workaround tarako target naming

Comment 55

[John Hopkins (:jhopkins)]

Comment on attachment 8391709 [details] [diff] [review]
workaround tarako target naming

One nit: be more specific what "weird names" means in the comment.

Comment 56

[Chris AtLee [:catlee]]

Comment on attachment 8391709 [details] [diff] [review]
workaround tarako target naming

hope to deploy this later today when I have some time to babysit

Comment 57

[John Hopkins (:jhopkins)]

Merged to production.  I have kicked off a new tarako build and will keep an eye on it.

Comment 58

[John Hopkins (:jhopkins)]

Build went green: https://tbpl.mozilla.org/?tree=Mozilla-B2g28-v1.3t&rev=bd3aefdc9a2a

Comment 59

[Chris AtLee [:catlee]]

The .zip files don't contain anything useful...patch incoming

Comment 60

[Chris AtLee [:catlee]]

Attachment: fix paths to image files

Comment 61

[Carsten Book [:Tomcat]]

seems we need tarako builds also on b2g-inbound at least since tarako fixes land here too like https://hg.mozilla.org/integration/b2g-inbound/rev/e3f743545ef1

Comment 62

[Ed Morley [:emorley]]

11:41 edmorley Seems like the intention was to only be b2g 1.3t branch only https://bugzilla.mozilla.org/attachment.cgi?id=8389490&action=diff
11:42 edmorley Tomcat|sheriffduty: so maybe hide on trunk trees for now and comment in the bug that they need switching off for trunk if not intended there (or else enabling on more than m-c if they want them running after all)

Comment 63

[[:fabrice] Fabrice Desré]

(In reply to Carsten Book [:Tomcat] from comment #61)
> seems we need tarako builds also on b2g-inbound at least since tarako fixes
> land here too like
> https://hg.mozilla.org/integration/b2g-inbound/rev/e3f743545ef1

Current tarako builds are on the 1.3t branch which is 1.3 + (cherry picked patches from trunk). So we absolutely needs the 1.3t builds, and will need trunk builds soonish (ideally one we are on 1.5)

Comment 64

[Aki Sasaki (not active)]

From the meeting:

[17:22]	<nhirata_>	aki: I have the answer to your build issue after finding the tinderbox build for tarako. the system image system.img can't be larger than 95k else it freezes when trying to flash the phone.
[17:23]	<aki>	nhirata_: i wasn't aware there was a build issue :)  i'll put that in the bug

* jsmith is wondering where nightlies are
* our current upload dir is "mozilla-b2g28_v1_3t-sp6821a_gonk-eng"; is this going to become something more intuitive?

Comment 65

[[:fabrice] Fabrice Desré]

The max size is 95M, not 95k - that would be really hard ;)

Comment 66

[Aki Sasaki (not active)]

(In reply to Aki Sasaki [:aki] from comment #64)
> [17:22]	<nhirata_>	aki: I have the answer to your build issue after finding
> the tinderbox build for tarako. the system image system.img can't be larger
> than 95k else it freezes when trying to flash the phone.
> [17:23]	<aki>	nhirata_: i wasn't aware there was a build issue :)  i'll put
> that in the bug

This should read "95mb", not "95k" :)

Viral: do you know how we can keep the system.img size down?

Comment 67

[Kai-Zhen Li [:seinlin][:kli]]

Aki: as I know the max size of system.img can be 105MB. 
The simplest way to downsize the system.img is move App to /data/local, here is a patch.
https://github.com/Seinlin/tarako-patches/blob/master/all-sp6821a_gonk/gaia/0002-Install-gaia-in-data.patch#L42

Comment 68

[thomas tsai]

No WIP for tarako now:

1. git clone https://github.com/mozilla-b2g/B2G
2. cd B2G
3. BRANCH=v1.3t ./config.sh tarako
4. ./build.sh -j1

Comment 69

[Brian Huang [:brianhuang][:brhuang]]

Aseking, please check this from Thomas. Thanks.

Comment 70

[viral [:viralwang]]

I think comment 67 already provide the patch to move apps to /data
That should reduce the size of system.img.

Comment 71

[Askeing Yen[:askeing][:fyen]]

TPE server use the patches of comment 67 to downsize the system.img. 
And it also generate gaia/gecko packages without patches.

Comment 72

[thomas tsai]

The system.img is too big to rom update, so remove fonts to shrink rom size.
https://github.com/Seinlin/tarako-patches/blob/v1.3t/all-sp6821a_gonk/external/moztt/0001-shrink-fonts-size.patch

Comment 73

[Al Tsai [:atsai]]

No idea about what to provide? Thomas, could you be specific your question please? Thanks :)

Comment 74

[thomas tsai]

No WIP now for tarako, so the system.img is over 120MB. We should make PVT build work, so some fonts should be removed to shrink the rom size. The provided patch is to remove fonts to shrink rom size.

Comment 75

[Joe Cheng [:jcheng] (please needinfo)]

Aki, does the suggestion on comment 74 helps? thanks

Comment 76

[Joe Cheng [:jcheng] (please needinfo)]

from https://bugzilla.mozilla.org/show_bug.cgi?id=981160#c18, we should take care of localizations as well

Comment 77

[Aki Sasaki (not active)]

(In reply to Joe Cheng [:jcheng] from comment #75)
> Aki, does the suggestion on comment 74 helps? thanks

Comment 67 and comment 72 both have patches to decrease the system.img size, thank you.
When will one/both of these land?

Comment 78

[Joe Cheng [:jcheng] (please needinfo)]

Thomas, can we land comment 67 and comment 72 to unblock PVT build for now? thanks

Comment 79

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

bug 985363 also talks about multilocale for 1.3T

Comment 80

[James Zhang (Spreadtrum)]

(In reply to Joe Cheng [:jcheng] from comment #78)
> Thomas, can we land comment 67 and comment 72 to unblock PVT build for now?
> thanks

What does 'PVT' mean? Please ni? me.

Comment 81

[James Zhang (Spreadtrum)]

We add all 24 country language which v1.3 support, the system image size is 140MB, exceed about 35MB.

Comment 82

[Aki Sasaki (not active)]

(In reply to James Zhang from comment #80)
> (In reply to Joe Cheng [:jcheng] from comment #78)
> > Thomas, can we land comment 67 and comment 72 to unblock PVT build for now?
> > thanks
> 
> What does 'PVT' mean? Please ni? me.

pvt means private, as in not on the public ftp server.

Comment 83

[Joe Cheng [:jcheng] (please needinfo)]

Let's unblock with English only locale build for PVT. This should make the system.img under than 105MB for flashing. ni? Ttsai for landing such change

Comment 84

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: Remove some fonts to reduce system.img size

Hi Michael, I think we need to remove some fonts to make the system.img size small enough for pvt build at this moment. And this pull is only to v1.3t.

Comment 85

[Michael Wu [:mwu]]

(In reply to Kai-Zhen Li from comment #84)
> Created attachment 8395603 [details] [review]
> Remove some fonts to reduce system.img size
> 
> Hi Michael, I think we need to remove some fonts to make the system.img size
> small enough for pvt build at this moment. And this pull is only to v1.3t.

There's been work on this in bug 985363.

Comment 86

[Tony Chung [:tchung]]

clearing my ni? since others stepped in to help.

Comment 87

[Joe Cheng [:jcheng] (please needinfo)]

can we land attachment 8395603 [details] [review] first so we can generate PVT build? 
it seems like we need some more time to figure out how to properly handle multilocale builds
thanks

Comment 88

[Chris AtLee [:catlee]]

Attachment: enable tarako non-eng and nightlies

Comment 89

[Joe Cheng [:jcheng] (please needinfo)]

ni? Marco for comment 87

Comment 90

[Marco Chen [:mchen]]

(In reply to Joe Cheng [:jcheng] from comment #89)
> ni? Marco for comment 87

Hi Joe,

Sorry to that I am not familiar with fonts stuff so I can't give a review then land it.

Comment 91

[Hema Koka [:hema]]

Mike Wu, 

Please take a look at this and provide help with reviews and moving it forward.

Thanks
Hema

Comment 92

[Justin Wood (:Callek)]

Comment on attachment 8396857 [details] [diff] [review]
enable tarako non-eng and nightlies

this patch is now live http://hg.mozilla.org/build/buildbot-configs/rev/6b1a60e4112c

Comment 93

[Michael Wu [:mwu]]

Comment on attachment 8395603 [details] [review]
Remove some fonts to reduce system.img size

Charis SIL cannot be removed as it is our serif font. There are patches on bug 985363 that you should assist with instead.

Comment 94

[Kai-Zhen Li [:seinlin][:kli]]

(In reply to Michael Wu [:mwu] from comment #93)
> Charis SIL cannot be removed as it is our serif font. There are patches on
> bug 985363 that you should assist with instead.

Michael, OK, I'll follow this on bug 985363.

Comment 95

[Chris AtLee [:catlee]]

Let's close this bug out. We have builds running. Subsequent issues should be in their own bugs.

Comment 96

[Joe Cheng [:jcheng] (please needinfo)]

Hi Chris,
do we actually have flashable PVT builds available? 
IIRC, they are too big the be flashed into actual devices

Comment 97

[Aki Sasaki (not active)]

(In reply to Joe Cheng [:jcheng] from comment #96)
> Hi Chris,
> do we actually have flashable PVT builds available? 
> IIRC, they are too big the be flashed into actual devices

I think that's tracked in bug 985363.
Also, I think someone needs to green up the 1.3t branch... https://tbpl.mozilla.org/?tree=Mozilla-B2g28-v1.3t

Comment 98

[Michael Wu [:mwu]]

Temporarily disabled reordering to see if things behave better -
https://github.com/mozilla-b2g/gaia/commit/dfcc7f8fb35f6c17d6e6556e2ef3ff8c7478d06e

Comment 99

[Michael Wu [:mwu]]

(In reply to Michael Wu [:mwu] from comment #98)
> Temporarily disabled reordering to see if things behave better -
> https://github.com/mozilla-b2g/gaia/commit/
> dfcc7f8fb35f6c17d6e6556e2ef3ff8c7478d06e

Reverted in https://github.com/mozilla-b2g/gaia/commit/17e3c51c039dde2bcd2c7ac0e55076f15a08d199 . No apparent change.

Comment 100

[Michael Wu [:mwu]]

Attachment: Avoid race in kernel build

It looks like we're trying to build the kernel and install the kernel headers at the same time. This patch should eliminate the problem, though I can't verify it locally.

Comment 101

[Michael Wu [:mwu]]

James, would it be possible to commit this patch (Avoid race in kernel build) to the kernel repo? I think it'll help with our build issues here.

Comment 102

[James Zhang (Spreadtrum)]

(In reply to Michael Wu [:mwu] from comment #101)
> James, would it be possible to commit this patch (Avoid race in kernel
> build) to the kernel repo? I think it'll help with our build issues here.

Ying has fixed it.

Comment 103

[nitturi.shiva]

trying to build fot alcatel one touch fire c, build.sh fails with following msg

"-- Could NOT find procps (missing:  PROCPS_LIBRARY PROCPS_INCLUDE_DIR) 
CMake Error at CMakeLists.txt:256 (message):

GNU 4.4.x compiler does not support C++11"..

>>log  from errorLog file is
/home/nitturis/firefox/new/B2G/prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin/arm-linux-androideabi-g++   -DANDROID -fexceptions -frtti -fpic -Wno-psabi --sysroot=/home/nitturis/firefox/new/B2G/prebuilt/ndk/android-ndk-r7/platforms/android-9/arch-arm -funwind-tables -finline-limit=64 -fsigned-char -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -fdata-sections -ffunction-sections -Wa,--noexecstack  -fvisibility=hidden -DCXX_COMPILER_FLAG_STD_GNUXX11 -fPIE -isystem /home/nitturis/firefox/new/B2G/prebuilt/ndk/android-ndk-r7/platforms/android-9/arch-arm/usr/include -isystem /home/nitturis/firefox/new/B2G/prebuilt/ndk/android-ndk-r7/sources/cxx-stl/gnu-libstdc++/include -isystem /home/nitturis/firefox/new/B2G/prebuilt/ndk/android-ndk-r7/sources/cxx-stl/gnu-libstdc++/libs/armeabi-v7a/include -isystem /home/nitturis/firefox/new/B2G/prebuilt/ndk/android-ndk-r7/sources/cxx-stl/gnu-libstdc++/include/backward    -std=gnu++11 -o CMakeFiles/cmTryCompileExec4144841629.dir/src.cxx.o -c /home/nitturis/firefox/new/B2G/out/target/apitrace/CMakeFiles/CMakeTmp/src.cxx
cc1plus: error: unrecognized command line option "-std=gnu++11"