(2013/04/03 16:32), ishikawa wrote: > On (2013年04月03日 15:32), Mike Hommey wrote: >> On Wed, Apr 03, 2013 at 02:22:35PM +0900, ishikawa wrote: >>> 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. >> >> Try gold with gcc 4.7. >> >> Mike > > thank you. Will do and report my experience tomorrow. >
I tried gold, GNU gold (GNU Binutils 2.23.2) 1.11 on my local PC and and it was very impressive. I did not realize that I needed to run --with-gold or run ./configure under ./gold directory of binutils distribution to create gold binary. Also, you need "bison" instead of Berkley-derived yacc to parse .y file correctly. Now, using gold, I could link the code compiled by gcc 4.7, gcc (Debian 4.7.2-5) 4.7.2, to be exact. I set the PATH to PATH=$HOME/bin:/bin:/usr/bin after I installed /usr/local/bin/ld.gold and created ~/bin/ld as a script to run /usr/local/bin/ld.gold $* The link time certainly decreased much : but it is hard to measure only the ld link time since top-level |make| invokes many small steps which amount to several minutes no matter what on my local PC (I am building DEBUG BUILD of thunderbird from comm-central with --enable-test. I am afraid that the test installation prepares test environment setup ALWAYS...) But the major factor that has made it possible for me to link the code generated by gcc-4.7 under linux 32bits, (uname output is : Linux debian-vm 3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux) is the reduction in the memory usage at link time of libxul.so (this is where the normal "ld" ran out of memory.) think). I ran "top" while compiling the source tree a few times after changing a source file. With the stock ld, I saw RSS grows to 2.9GB and when this memory limit is reached the system experienced heavy paging and I could not do much else. [I began seeing strange memory exhaustion errors about a week ago. So after that, I have monitied top output very carefully, and xosview gave an overall view of what goes on about the memory usage.] With gold, the largest RSS I saw was 1.9GB and from the look of xosview, I still have maybe 500MB left in the memory space and so I could edit files using Emacs in parallel without problems at all. Where it is applicable, gold seems to be a tool of choice. (I saw mention of the failure to compile linux kernel modules and such. So, it is not universally applicable yet if I am not mistaken. Some blogs and such warn of not replacing "ld" with "ld.gold" without saving the origianl copy somewhere. ) Right now, I am running the compiled and linked DEBUG BUILD of TB (comm-central) by invoking "make mozmill" to test if anything unwanted my have crept in using "gold". I think with gcc 4.7, gold may become the necessary linker for mozilla build under linux 32 bits, and even under linux 64bits version due to the speed increase. In my case, if is either being able to compile&LINK with gcc-4.7 and gold, or needing to downgrade to gcc-4.6. But the memory usage reduction alone would make me want to use gold for mozilla software build if no serious bugs creep in. TIA _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
