On 2016/12/24 1:54, Nathan Froyd wrote:
On Fri, Dec 23, 2016 at 11:37 AM, Mike Hoye <mh...@mozilla.com> wrote:
On 2016-12-23 11:08 AM, Nathan Froyd wrote:
Bug 1322792 has landed on inbound, which changes configure to require
GCC 4.9 to build; our automation switched over to GCC 4.9 for our
Linux builds earlier this week. (Android builds have been using GCC
4.9 for some time.)
I happened to be poking at the MDN docs when this came in, so I'll update
them to reflect this.
Thank you!
I haven't tested our minimum hardware recommendations on Linux - 2GB ram,
30GB free space - recently, but I'll test them in the new year.
For 64-bit Linux, I think you need 4GB at the absolute minimum (build
may start swapping), and 8GB would be better. My rule of thumb is
that you need a minimum of 2GB/thread that you're compiling with on
64-bit Linux (e.g. 16GB on a 4 core/8 thread machine); some of our
autogenerated files take lots of RAM to compile, and you want to have
a little bit left over for applications.
Anyone know offhand if it's still possible to build on a 32-bit Linux box?
We haven't been able to build on 32-bit Windows for a while now.
I suspect it's possible, based on halving the RAM from a 64-bit build,
but I haven't tried it.
-Nathan
I used to compile C-C TB in 32-bit environment, but it required GNU
gold, ld.gold linker. This is a must if someone tries 32-bit build.
This is because, circa three years ago or so, ordinary ld linker started
to run out of memory space during linking (its internal table became too
large for 32-bit memory space). I had switched to GNU gold linker
because it was faster, but it also used much smaller memory area. (Going
over 2GB or not was crucial for 32-bit memory space build.)
When I noticed the ordinary linker started to blew up due to 32-bit
limit, switching to GNU gold linker kept me building C-C TB on 32-bit
linux. I did this for a year or so.
Also, you may have to run with -gsplit-dwarf so that debug symbol
generation is somewhat different from the default method, but this I am
not sure. Again, for -gsplit-dwarf to work effectively, you need to use
GNU ld linker, I think.
I noticed the memory space issue for 32-bit linux around the time when
compiling and linking for linux binary began using 64-bit linux in the
compilation farm. It was not easy for me to switch my desktop linux PC
to 64-bit, so I stuck to 32-bit linux for a while.
But I needed to switch to GNU gold linker due to the reasons above.
Since then, though, I have switched to 64-bit linux now.
The 32-bit machine's power unit died and when new installation in a new
box was necessary, I decided to use 64-bit.
I am using Debian GNU/linux 64-bit and so far it works fine. I think the
compilation farm of mozilla uses CentOS, but as far as the toolchain
goes, there does not seem to be much difference today. (Debian's g++ was
broken for mozilla software for half a year about 4 years ago. It could
not grok subtle name scope issues: Debian's g++ had its own original
patches. Also, Debian tended to stick to very old stable versions.
But recent GCC development has a very quick turnaround in contrast to
the old days, and Debian now releases the GCC following the regular GCC
updates. So users may encounter less such problems now. I have not
noticed Debian-specific issues for building for quite a while. Debian's
iconv seemed to have a subtle issue for a long time, but that is
separate from build issues.)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
