FYI: Upgrading binutils to 2.23.2 did not help. (Well, at least I got a better memory usage report when memory was exhausted. "ld" printed out that it fails to allocate this many bytes after having allocated the total amount. They are printed numerically. It was close to 1GiB and so I assumed it is hitting some 32-bit linux limit (my linux kernel is PAE kernel.)
Downgrading to gcc-4.6 and g++-4.6 helped. Specifying gcc-4.6 and g++-4.6 explicitly during configure, I could compile TB and run test again. Hope this helps. On (2013年04月02日 20:01), ishikawa wrote: > On (2013年04月02日 13:58), ishikawa wrote: >> On (2013年04月02日 13:52), ishikawa wrote: >>> [I just noticed that in a follow-up post that LTO pass requires 6GB of >>> memory on 64bits linux, >> >> Ooops: A typo of my own: it was not *6*GB but *3*GB in the GCC note. >> >> But funny, the ld seems to give up hands immediately now >> (a few days ago, it tried to use up memory space by using swap and all that. >> Something has changed.) >> > > I think the problem I am seeing with TB build may be a different issue. > > Come to think of it, I have been using -O for optimization since > I want to run the DEBUG BUILD of TB under valgrind/memcheck. > (So it should not run PGO, correct?) > > An explicit method to disable PGO just in case will be appreciated. > Is it as follows? > > mk_add_options MOZ_PGO=0 > > > I suspect that libxul.so link now tries to accept more objects (maybe, pure > guess) and is choking for new TB build framework. > > Anyway I will check > - if newer "ld" solves the issue, or > - downgrading to gcc 4.6 will help. > > > > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
