As part of enabling integration tests for B2G/Gaia to run in the QEMU Emulator fork we maintain we'd like to provide builds for Darwin x86 as most of our developers currently run OS X (as well as Linux, but, Linux builds are already provided). As far as I know, building wouldn't require any particular configuration changes. The same configuration can be used to build the emulator as with any other B2G build. './config.sh emulator' takes care of the details. We'd be stoked if the builds were provided in the same spot as the current Linux Emulator builds, which is here: https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-generic/

(In reply to Ghislain 'Aus' Lacroix from comment #0) > As far as I know, building wouldn't require any particular configuration > changes. The same configuration can be used to build the emulator as with > any other B2G build. './config.sh emulator' takes care of the details. [11:36] <auswerk> aki: yeah, it can be done using the same b2g build method as for phones. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Preparing_for_your_first_B2G_build [11:37] <auswerk> config.sh can be called with the target "emulator" [11:37] <auswerk> as far as I know that's all that's required. there are no extra pre-requisites for the emulator. > We'd be stoked if the builds were provided in the same spot as the current > Linux Emulator builds, which is here: > https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla- > central-generic/ Would we be able to differentiate between the two? It might make sense to put them in, say, mozilla-central-generic-macosx/ or something, to a) avoid human confusion as to which binary to download for which platform b) avoid overwriting files since the linux emulator binaries are used by automated tests, and overwriting those with mac files may cause issues.

(In reply to Aki Sasaki [:aki] from comment #1) > > We'd be stoked if the builds were provided in the same spot as the current > > Linux Emulator builds, which is here: > > https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla- > > central-generic/ > > Would we be able to differentiate between the two? > It might make sense to put them in, say, mozilla-central-generic-macosx/ or > something, to > a) avoid human confusion as to which binary to download for which platform > b) avoid overwriting files since the linux emulator binaries are used by > automated tests, and overwriting those with mac files may cause issues. That would work for me, I'm also open to having the tarball filenames reflect which platform they were built for.

Any ETA on this? Just trying to figure out how to line up my other work. :)

AFAIK we don't have this prioritized against other work, so it's not currently being worked on. If this should be prioritized higher than other work, we can delay that other work for this.

We need this emulator setup to run/write a lot of our critical tests for v1.2 features. Talking with Aus he is completely blocked. How can we prioritize this ?

(In reply to James Lal [:lightsofapollo] from comment #5) > We need this emulator setup to run/write a lot of our critical tests for > v1.2 features. Talking with Aus he is completely blocked. How can we > prioritize this ? Do linux VMs work, or is there something that prevents those from running/writing tests? How important is this compared to gonk-jb emulator builds, or a hamachi beta channel, or a gaia-try branch, or tools to test manifest changes, etc? I can bring this up at Tuesday's cross functional meeting to make sure everyone agrees that one of the above items (or something else) can be de-prioritized for this.

I am unfortunately blocked at this point without those builds up and running. The next steps for me are to add support to automagically download and setup the emulator like we do for integration tests running against b2g desktop.

Wow, that's a tough one to be honest... I'm not sure how that stacks up compared to those other things you guys have lined up already. I would love to be able to complete emulator based integration tests this release so I can possibly work around it in the meantime by running a linux vm and using the current set of emulator builds, but, that will only get me as far as linux support and we're really shooting for both os x and linux out of the gates with this one as most of the gaia devs are on os x.

I still don't understand: I thought you were able to build this locally? I'm under the impression you can use a linux vm; is this not accurate? If either of the above is true, I think we have a different definition of "blocked", unless there are additional requirements I'm unaware of. (written before comment 8; sounds like you can use a linux vm, which leads to these questions: What would testing on OSX give you that is not covered by Linux emulators? Are the emulators different, or are the gaia apps somehow different? What bustage would testing on OSX give us that would not be detected on Linux?)

(In reply to Aki Sasaki [:aki] from comment #9) > I still don't understand: > > I thought you were able to build this locally? > I'm under the impression you can use a linux vm; is this not accurate? > > If either of the above is true, I think we have a different definition of > "blocked", unless there are additional requirements I'm unaware of. > (written before comment 8; sounds like you can use a linux vm, which leads > to these questions: > > What would testing on OSX give you that is not covered by Linux emulators? > Are the emulators different, or are the gaia apps somehow different? > > What bustage would testing on OSX give us that would not be detected on > Linux?) hi Ghislain, :lightsofapollo: This came up again in yesteday's cross-group priority meeting. Can you clarify why you need new OSX builds, instead of using the existing linux builds?

This was discussed at the B2G work week; most Gaia (and many other developers) use OS X and not Linux, and they need OS X builds for their work. Therefore, we need to run OS X builds on TBPL in order to prevent breakage.

(In reply to Jonathan Griffin (:jgriffin) from comment #11) > This was discussed at the B2G work week; most Gaia (and many other > developers) use OS X and not Linux, and they need OS X builds for their work. > > Therefore, we need to run OS X builds on TBPL in order to prevent breakage. Getting these builds on TBPL is going to do a couple of things for us: 1. Prevents people's local mac emulator builds from getting broken by random changes. 2. Ensures that folks running on mac have a viable test area for gaia changes or for running tests locally (running emulators is already slow, running emulators in VMs is even slower).

per today's cross-group-b2g meeting: 1) this was missed from RelEng's https://wiki.mozilla.org/index.php?title=User:Asasaki:B2GBuilds and also missed in clee/faramarz "what builds to drop/add" review last week. I've now added it to wiki along with the other pending build-types. 2) per dylan, these should be on v1.2 and also on v1.3/master.

dylan ping'd me about this yesterday. Some other projects bumped this, so I'm looking for someone else who can work on this.

Taking bld-lion-r5-087 from pre-production to work on this.

To help me keep notes as I go along, I've created this blog post: http://petemoore.tumblr.com/post/66705593417/building-b2g-emulator-on-darwin

Hi Ghislain, We're close to setting up these builds - we have some issues we need to work through regarding upgrading our build infrastructure to have the right versions of dependencies (gcc compiler etc) - so this is currently work in progress. However, ... taking a step back ... , I realised it *may* be worthwhile seeing if we can stand up these builds on our linux infrastructure, i.e. building *mac* emulator builds on linux infrastructure (cross-compiling). However, before we even look into this possibility (which may have merit, since we can spawn amazon linux instances on-the-fly, and grow elastically to meet demand, rather than needing in-house mac minis) - I wanted to check with you whether such a model would still support your requirements. For example, would you have any issue with us building these mac builds on our linux infrastructure? Is your objective to have binaries that can be downloaded and tested, e.g. from tblp / ftp, or is your objective (for example) to make sure that as soon as emulator builds fail on native mac hardware, that the CI breaks? This could affect the merit of building on linux, since it may (or may not - we would need to further investigate) be the case that a mac emulator build might break when built on mac, yet the same mac emulator build *built on linux* might not. In this case, we might not "catch" the breakage on native mac platforms, yet still are able to generate mac binaries that can be run on mac. Depending on your requirements, this may or may not be a problem. So this hangs a little bit on your reasons for wanting these builds in the first place. We do currently have native mac desktop builds of B2G - I am guessing that you are only interested in emulator builds, so this existing setup does not meet your requirements. I'm on IRC mostly in european time (:pmoore) if you want to talk this through in real time - otherwise via this bug is also cool. My assumption (please let me know if I am wrong) is that the builds we create include the emulator code (sorry I have not got so far yet, so haven't tested) - so that the build is a standalone application with the emulator embedded inside - rather than generating a binary which is interpreted by an emulator application which is already installed on the system. My assumption would be if we are generating some kind of virtualised byte-code that runs inside an emulator, it would be platform independent, since it would be interpreted by the emulator - but my understanding is that the interpreter is some kind of embedded interpreter, so that the whole package that gets built at the end is a native application, with an emulator layer under-the-hood, and for *this* reason we need to build for both linux and mac. Let me know if I've misunderstood! Thanks, Pete

Managed to get emulator build running on a machine in our build farm (bld-lion-r5-087.build.releng.scl3.mozilla.com). This attachment is a screenshot of the emulator running. Some work to do now, to get this integrated into our build system, and validate that the changed versions of tools this requires does not break any other builders on these slaves (if necessary, may need some form of 'chroot'ing to isolate dependencies to their respective builders).

When grabbing a machine, we open the machine's bug and block on the bug where it is being used. For example, I re-opened this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=bld-lion-r5-087 and blocked on this current bug. Once the machine is not needed, either close this bug (if done) or remove the dependency and make a comment. This way buildduty can direct you on how to put it back into produciton. Good luck on your hacking! PS=I'm not CCing.

Thanks Armen for the explanation - that makes sense, will do this in future. Thanks, Pete

So an update! The two dependent bugs have now been resolved, so we are able to build emulator for darwin in our test environment without any hacks. The steps are all scripted up, and now the following tasks remain: 1) Converting all the package installations into puppet config, so that puppet will setup our darwin builders properly. 2) Verifying whether we want to maintain two different git versions on the darwin build machines, or testing the new version of git for the other builders that are currently using it 3) Creating script factories in build bot for managing the new builders 4) Testing everything in staging, and rolling out to production 5) Getting results integrated with tbpl Due to the fact I'll be on leave for most of December, it is not realistic that this will get implemented until the beginning of next year. Thanks, Pete

Incidentally, we have managed to: 1) upgrade from using python 2.7.1 to use python 2.7.3 without needing to go all the way to 2.7.6 - 2.7.3 is also on all the darwin builders, so we no longer need this dependency, we just need to fix the PATH 2) we have managed to get around upgrading xcode and command line tools to a later version than is currently on the boxes (this would have been a real nightmare) by doing a one-time upgrade, building gcc from source, and then storing the gcc binaries. The upgrade was only necessary as a vehicle for building gcc - it is not a runtime dependency on the build process itself, so once built, we keep a copy, and then go back to using the old xcode / command line tools. 3) we have managed to emulate the brew install steps, by storing the packages that get generated under /usr/local/Cellar, and creating appropriate symlinks to make the binaries available in PATH, and sym-linking necessary .dylib files under /usr/local/lib (also need to check this has no adverse affect on other builders, or if we can place in a different location and set some kind of LD_LIBRARY_PATH or equivalent on darwin). 4) i will submit another patch - this time to fix this line: https://github.com/mozilla-b2g/gonk-misc/blob/master/Android.mk#L354 which currently works on gnu-tar, but not on the default tar installed on darwin (bsdtar 2.8.3 - libarchive 2.8.3). It does not support the --transform option. If we get the --transform options out of this line, this should remove the current dependency on installing gnu tar too, which also simplifies matters (also nice for mac developers not needing it either).

Famous last words - we're not out of the woods yet - need to find out what is causing this. Will look at this tomorrow... I'm currently testing installing dependencies as binaries, and not upgrading xcode / command line tools - this could be fallout from this change - will update the bug when I have more info. 16622 11:34:25 INFO - configure: error: Your host toolchain does not support C++0x/C++11 mode properly. Please upgrade your toolchain 16623 11:34:25 INFO - *** Fix above errors and then restart with "make -f client.mk build" 16624 11:34:25 ERROR - make[3]: *** [configure] Error 1 16625 11:34:25 ERROR - make[2]: *** [/Users/cltbld/b2g_build/build-dir/build/objdir-gecko/Makefile] Error 2 16626 11:34:25 ERROR - make[1]: *** [build] Error 2 16627 11:34:25 INFO - make: *** [out/target/product/generic/obj/DATA/gecko_intermediates/gecko] Error 2 16628 11:34:25 INFO - real 30m27.760s 16629 11:34:25 INFO - user 23m33.428s 16630 11:34:25 INFO - sys 3m10.043s

ah looks like i just need to fix the PATH for c++ - fixed and retrying...

fixed! now i have next problem .... will fix this tomorrow 3310 11:59:18 INFO - host C++: aidl <= frameworks/base/tools/aidl/aidl.cpp 3311 11:59:19 INFO - g++: error: frameworks/base/tools/aidl/aidl.cpp: C++ compiler not installed on this system 3312 11:59:19 INFO - make: *** [out/host/darwin-x86/obj/EXECUTABLES/aidl_intermediates/aidl.o] Error 1 3313 11:59:19 INFO - real 0m15.134s 3314 11:59:19 INFO - user 0m5.253s 3315 11:59:19 INFO - sys 0m4.184s

Hi Pete, Sorry for the delay! The goal here is to be able to download this emulator via ftp/http to do full test runs on travis-ci as well as tbpl. We also need these to be available for OS X as most of us use Macs and need to run these test suites locally. The emulator itself is meant to emulate the hardware which in turn will run a system image that's comprised of b2g + gaia + tests. Just like we can run the integration tests locally using b2g-desktop for mac builds, we want to be able to do the same via the qemu emulator. Hope that all makes sense. :)

Quick update: bld-lion-r5-087.build.releng.scl3.mozilla.com (the machine we are using for our tests) has been re-provisioned and the dependencies required to build the emulator have been installed as pre-packaged binaries; the machine setup includes some changes to address the problem described by Pete in Comment 25. The package installation is fully scripted, which should make the next step (packages installation via puppet) easier, once all the build issues are solved. A build is currently running to verify whether the previously mentioned compilation issue is solved by our last changes. PS: Thanks to Pete for the time he spent working with me on this Bug in the past two days, even if he was on PTO!

Hi Marshall, In the mozilla.dev.b2g forum (namely, here: https://groups.google.com/forum/#!topic/mozilla.dev.b2g/qaupSswnuYg ) you suggest a solution to the following compilation problem: duplicate symbol dyld_stub_binding_helper in: /usr/lib/crt1.10.5.o /usr/lib/dylib1.o ld: 2 duplicate symbols for architecture i386 collect2: ld returned 1 exit status make: *** [out/host/darwin-x86/obj/EXECUTABLES/triangleCM_intermediates/triangleCM] Error 1 Your patch actually solved the problem in our test environment for b2g emulator builds as well. Do you think this patch should be landed to the b2g codebase? Is there a risk of introducing problems for the other targets (non emulator ones)? Thanks a lot! Simone

I can definitely submit a pull request to our emu-fix branch on our fork of the sdk project. This should isolate it from other device builds, so I don't think it will add any risk for other targets. I've opened Bug 949091 to track this.

For the curious, this is where we are tracking our work: https://github.com/petemoore/b2g_emulator_build_darwin In here, we have two different environment setup scripts: setup.sh and setup2.sh. The first (setup.sh) is a setup script that allows us to set up all the machine dependencies by first installing homebrew, and then downloading homebrew packages. It also involves updating command line tools, in order to be able to build the gnu gcc compiler. The second (setup2.sh) is a setup script which does *not* update command line tools, and does *not* install homebrew. Instead, it takes the packaged binaries that were created with setup.sh, and installs these binary packages, and takes care of creating symlinks where necessary. So the reason we have two separate setup scripts, is so that the first one can be used to create one-time binary packages, and the second one simply uses these binary packages. Another advantage of this is that it is much simpler to create a setup which does not involve changing the xcode version or command line tools version on the system. Please note the current bootstrap-mac.sh script that exists in B2G project (https://github.com/mozilla-b2g/B2G/blob/05b336020a7df015dcea453d8c52dc77f458a7f1/scripts/bootstrap-mac.sh) only installs c compiler by default, not c++ compiler. Therefore on systems that are currently using this, it looks like they can only work by compiling C code using the gnu gcc compiler, and that C++ code would get compiled by the native xcode gcc-llvm compiler. However, for the emulator builds we are creating we prefer to consistently use the same compiler, and therefore we have adapted the gnu gcc compiler to be able to compile C++ code too, and use *only* this compiler for all steps. We will be submitting a further patch to B2G to provide a fix for this. As soon as this is ready, it will no longer be necessary to have any xcode / command line tools compiler on your system, and only the gnu gcc compiler, compiled with the right capabilities. Pete

I should add, after setup.sh or setup2.sh is run, from a fresh darwin image (i.e. after we reimage a machine in our network), to build the emulator, we run compile.sh. So one time run only of setup.sh or setup2.sh required, and then compile.sh may be run every time a compile is needed. Please note these are not the scripts that will be used in the end - this is simply our way of tracking the necessary steps, before converting to mozharness/buildbot/puppet configuration/scripts. Please also note, the "Cellar" directory contains all the binary packages we created using brew in setup.sh. Please also note that create_all_links.sh is the script that generates all_links.sh - which is the script called by setup2.sh that adjusts all symlinks on the system required for the packages under Cellar. Pete

Thanks for the recap Pete, the Mac setup process for developers / contributors could definitely use these improvements :)

At this stage, I think the machine setup and the build procedure as it has been implemented with setup2.sh + compile.sh scripts (see Comment 30) needs to be validated by dev, before being ported to the build infrastructure. Please note in particular that we are now using the gcc compiler for all compilation phases, while the procedure described in https://developer.mozilla.org/en-US/Firefox_OS/Firefox_OS_build_prerequisites (which makes use of the bootstrap-mac.sh setup) uses the xcode gcc-llvm compiler AND gnu gcc compiler for different compilation tasks (see Comment 30). Please also note that, once validated, this build setup and compilation script could also be adopted by devs/contributors for local builds. Marshall, I am putting your name in the needinfo request because so far you were our main contact point with development, but feel free to point us to anybody able to help! I can help out in case you need to loan a machine to run some tests, or you have questions about the procedure implemented in https://github.com/petemoore/b2g_emulator_build_darwin

I would propose that in order to avoid delays, we could deliver the darwin emulator builds "as-is" (built as we currently build them), with a disclaimer "if you need any changes to the process, please let us know" - e.g. if later it is decided to switch compiler, that should be a not-so-big change to implement, hopefully - and this way, we can get something out-the-door which can be "tuned" later if needed, but has the advantage that all the work to get them in tbpl, set up the new buildbot factories etc, is all done already. Is that also ok with you Marshall and Ghislain? Pete

Pete, that sounds great to me!

Hi guys, I'm working in parallel on some other bugs, but I hope to get back to this (part-time only) at the start of next week (24 Feb). Thanks, Pete

Am in the process of reimaging bld-lion-r5-086 for this work...

Simone: I asked Pete to shift this back to you. You have recent experience getting things deployed from the b2g debug builds, and hopefully have the same state as Pete with regards to this emulator build. There isn't be a test component here (build-only), so assuming the build still works, it *should* be a quick deploy.

Coop: ok, first step will be to check that the build is still working by building on a freshly re-imaged slave (I'll be using bld-lion-r5-043).

We've been blocked here for a while. Will Mulet builds mitigate the need for this? https://groups.google.com/forum/#!msg/mozilla.dev.b2g/2WUg10993OM/VSceN9i2w2EJ

(In reply to Aki Sasaki [:aki] from comment #40) > We've been blocked here for a while. > Will Mulet builds mitigate the need for this? > https://groups.google.com/forum/#!msg/mozilla.dev.b2g/2WUg10993OM/ > VSceN9i2w2EJ Not directly. We'll still be using the emulator, and it will be the only way to test some things on a per-commit basis.

Status update Apart from the issue described in Bug 1009484, I am having new compilation issues (see next attachment). I found groups and sites discussing the same issue I am having while building Android; some of the proposed solutions are related to repo sync commands; incidentally, the mozharness code dealing with repo sync commands changed in the past weeks, so the two things *could* be related. I am currently investigating this, and I'll ask dev support if needed.

The scripts I am currently testing to run the build are in https://github.com/simone-mozilla/b2g_emulator_build_darwin, forked from pete's repository. I am currently trying to run a build on bld-lion-r5-086 after re-imaging.

Some of the scripts needed to be changed to adapt to recent mozharness changes. After these changes, I am now getting a similar compilation issue as the one described in comment 43: the build fails while compiling external libraries (namely, the iptables one). - I setup the machine using https://github.com/simone-mozilla/b2g_emulator_build_darwin/blob/master/setup2.sh - The script i am using to compile is https://github.com/simone-mozilla/b2g_emulator_build_darwin/blob/master/compile.sh - The full log of the build is http://people.mozilla.org/~sbruno/compile_bld-lion-r5-086.build.releng.scl3.mozilla.com_2014-07-03_07.33.16.log Mshal: I need some help here! Can you have a look to the build log file above? Is there any trivial reason for this build failure?

Hrm, are you doing this build on a case-sensitive or insensitive file system?

It's tough to say for sure since the log doesn't give the full command-line of the compiler. In addition to checking the case-sensitivity, can you see which xt_CONNMARK.h file that compilation is actually using? You may be picking up a different version of the file from a system include path instead of the in-tree one. Or, if you are getting an in-tree version, are you sure it's not an older one from a previous build? It's possible it was updated in the tree, but an older version still exists in a build directory and it hasn't updated properly. If you get the command-line, you can try to run it manually and add a '-H' flag to see what headers it's picking up (or just look at the dependency file if you get one).

marshall_law, mshal: thanks a lot for your hints! It's unlikely that the problem depends on older versions of xt_CONNMARK.h (or any other files, actually), since I experience the same issue on a freshly re-imaged box as well. I am using a case insensitive file system and, as both marshall and google suggest, that could be causing the problem. My first thought was to create a case sensitive formatted partition on the box I am using for tests and try the build there, but the mac boxes in the buildfarm are re-imaged with a RAID 0 setup so I am not sure how to proceed without messing up the whole system. I am reluctant to try to create a local case sensitive partition on my personal machine since my hard disk is encrypted so I would need to decrypt, create a partition and re-encrypt - time consuming and there's a risk I mess up completely with my environment. Besides, as a general note, one of the goals of this bug is to provide devs with a way to run a emulator build, and requiring a local case sensitive partition would probably make the solution impractical (to say the least). Anyway... Dustin: Is there a (relatively) simple way to provision mac minis with a case sensitive partition so that I can try to run this build there?

> Is there a (relatively) simple way to provision mac minis with a > case sensitive partition so that I can try to run this build there You can create a sparse image and mount it: https://source.android.com/source/initializing.html#creating-a-case-sensitive-disk-image

marshall_law: thanks a lot for the tip! This definitely seems to be the way to go. I am now attempting the first build on a 100g case sensitive image. I also started working on the following tasks: - converting the setup + build .sh scripts to mozharness - creating a builder to integrate this job into buildbot

Bingo! The problem reported above was actually caused by the file system case insensitivity. I now run into the same problem described in https://bugzilla.mozilla.org/show_bug.cgi?id=905742, probably because the patch proposed there by marshall_law has not been applied. As a workaround, I will apply that locally after checkout to see whether there are further compilation issues.

Whoops! The bug I wanted to mention in the previous comment is actually: https://bugzilla.mozilla.org/show_bug.cgi?id=949091

Status update: I solved the issue mentioned in the bug before, now I am having another problem similar to the one described here: https://bugzilla.mozilla.org/show_bug.cgi?id=837720. I suspect this can be solved by setting the system cc to use the correct compiler version as we did for gcc, g++ and c++ in https://github.com/simone-mozilla/b2g_emulator_build_darwin/blob/master/setup2.sh. Verifying this right now with a new build attempt.

I was able to solve the "#error "mfbt (and Gecko) require at least gcc 4.4 to build" error (see comment below) by explicitly setting what cc compiler to use as well (as for other compilers in setup2.sh), now the build fails but it's not clear to me what's actually happening since all commands prior to the failure seem to run successfully: http://people.mozilla.org/~sbruno/compile_bld-lion-r5-086.build.releng.scl3.mozilla.com_2014-07-08_05.31.28.log mshal: any idea about how to proceed?

(In reply to Simone Bruno [:simone] from comment #54) > I was able to solve the "#error "mfbt (and Gecko) require at least gcc 4.4 > to build" error (see comment below) by explicitly setting what cc compiler > to use as well (as for other compilers in setup2.sh), now the build fails > but it's not clear to me what's actually happening since all commands prior > to the failure seem to run successfully: > http://people.mozilla.org/~sbruno/compile_bld-lion-r5-086.build.releng.scl3. > mozilla.com_2014-07-08_05.31.28.log Maybe this is the problem? I'm not sure what Objective-C compiler it is trying to use, but maybe you need to explicitly set that as well. 06:01:07 INFO - cc: error: external/qemu/distrib/sdl-1.2.12/src/main/macosx/SDLMain.m: Objective-C compiler not installed on this system 06:01:07 INFO - make: *** [out/host/darwin-x86/obj/EXECUTABLES/emulator-arm_intermediates/distrib/sdl-1.2.12/src/main/macosx/SDLMain.o] Error 1 Also, we should probably add "***" as an error message in mozharness so it shows up more prominently (or maybe 'make: ***' so it doesn't catch things like "***********" being used as a separator like earlier in the log where java is all whiny)

Thanks mshal! Yes, apparently the way I solved the previous issue (setting the system cc compiler to GNU c compiler) has this side effect. I guess I will have to adopt the solution in https://bugzilla.mozilla.org/show_bug.cgi?id=837720 insted, i.e. properly set HOST_CC and HOST_CXX instead, while leaving the system cc compiler point to the llvm one.

glandium: I am currently having the following compilation problem: 02:56:54 INFO - In file included from ../../../dist/include/mozilla/Attributes.h:12, 02:56:54 INFO - from ../../../dist/include/mozilla/Assertions.h:16, 02:56:54 INFO - from /Volumes/android/b2g_build/build-dir/build/gecko/modules/libmar/src/mar_private.h:11, 02:56:54 INFO - from /Volumes/android/b2g_build/build-dir/build/gecko/modules/libmar/src/mar_create.c:12: 02:56:54 ERROR - ../../../dist/include/mozilla/Compiler.h:27:6: error: #error "mfbt (and Gecko) require at least gcc 4.4 to build." 02:56:54 INFO - In the directory /Volumes/android/b2g_build/build-dir/build/objdir-gecko/modules/libmar/src I would like to adopt the solution you suggest in https://bugzilla.mozilla.org/show_bug.cgi?id=837720 In which mozconfig file(s) should I set HOST_CC and HOST_CXX in order to solve this?

Interlude: a pause for reflection. ---------------------------------- I have somehow the feeling that we are not going in the right direction here. The setup and build procedures are really convoluted, and probably this is going to look like the most complex builder in our infrastructure: we need a heavily customized environment, with tools which are currently uninstalled in our boxes, creating a case sensitive disk image to run the build, applying patches on the fly... Have a look to the setup and compile scripts to see what I mean. At the moment I am still not able to get a working build. I am confident that this can be achieved in a few more iteration of find-compile-problem/fix-setup-and-build scripts, with the help of devs. Even after fixing the scripts to have a successful build, though, they would need to be translated into mozharness scripts and buildbot changes which - I suspect - would also be non trivial (to say the least). In particular, we would basically need to reinvent our environment to run this single build. I wonder whether there are simpler ways to satisfy the needs behind this bug, and whether the priority of this justifies the effort being put on it. Of course I am happy to keep working on this if needed, but at this stage I would like to assess whether we are giving the right priority to this task and, technically, we are going down a feasible path.

Wontfixing per https://groups.google.com/forum/#!topic/mozilla.dev.b2g/5D3eTawmFs0 .