Comment 101 for bug 1711337

I wrote an email to Chris Coulson, asking for some assistance with the cflags. Hopefully he'll read it.

What you're saying about hardware requirements is not really true. Firefox is pretty demanding in terms of memory, yes, but per job mostly. On amd64 and if you build with gcc, it needs roughly 700 to 800 mb of ram per thread, and roughly double as much if you pass debug cflags along. Thats as bad as it gets, the demand in ram decreases a lot if you take clang instead, which is also a little bit faster and the binary seems to be a little bit faster as well (I'm actually writing this post from a clang built firefox) However, situation on armhf is more tense, because if you aim to compile nativly they are often limited by the amount of ram per job. rpi2 has only ~900mb free available at boot time, so we end up with just 200mb per core. This is not enough if you use gcc for compilation, the device would swap a lot, whereas with with -j2 and 400mb per thread it only swaps during some hefty code sections around the java script engine and close to the finish of the build, during linking.

Swapping can be so slow, that it completly eats away the theoretical speed gain by allowing more cores to be used with make via -jN

Also I would like to mention that we propably have to stick to gcc for compilation, because you can use clang to compile firefox on amd64, but not on armhf, due to a linking error. I think it is the same as in #72 of this bug report:

../../media/libstagefright/Unified_cpp_media_libstagefright1.o: In function `stagefright::SampleIterator::getChunkOffset(unsigned int, long long*)':
../../media/libstagefright/Unified_cpp_media_libstagefright1.cpp:(.text+0x554): undefined reference to `free'
../../media/libstagefright/Unified_cpp_media_libstagefright1.o: In function `stagefright::SampleIterator::getSampleSizeDirect(unsigned int, unsigned int*)'

At the moment trying to use gold linker instead of bfd, we'll see if that makes a difference.