(Sorry for top posting.) You may want to use GNU gold linker if you don't use it already. (I am assuming that you are compiling under posix-compliant systems such as linux or MacOS X. You mention .so, thus Windows can be ruled out, I suppose.)
Use of GNU gold linker has sped up link speed very much for me. It is indispensable now. Also, you might want to use -gsplit-dwarf compiler option, which forces GCC to store part of debug information in a separate file from the main object file: That is, GCC transforms source.c into two files: source.o and source.dwo source.dwo contains the bulk of debug information although source.o still contains some debug information. GNU gold linker needs to handle only source.o, leaving source.dwo alone, thus I/O during linking is reduced very much: faster execution time! Using GNU gold liner with -gsplit-dwarf cut down my link time very much under 32-bit linux AND the processing uses much less virtual memory: actually without -gsplit-dwarf and GNU gold linker, I began running out 32-bit address space of 32-bit Debian GNU/linux during linking of full DEBUG-version of TB a couple of years ago. So thunderbird could not be built any more under 32-bit linux. Then I learnt of GNU gold. With gcc -gsplit-dwarf and GNU gold linker, I could link thunderbird under 32-bit linux and linking of libxul went down to a few minutes from a dozen minutes! Unbelievable at first, but it is true. (But now I am using 64-bit linux for main development due to other reasons. I do compile 32-bit TB under 32-bit linux occasionally to test a local patch of the moment. So I am sure that TB can be linked with -gsplit-dwarf and GNU gold linker under 32-bit linux today. At least I could do so early this month.) Also, if you are under linux or posix-variant OS, you may want to install ccache to avoid unnecessary compilation. That helps when one need to shuffle patch queues using hg qpush/qpop commands. They update the source file's modified time thus forcing re-compilation even if the content remains the same as before when you compiled them last :-( ccache can help us here by looking at the preprocessed source file and decides if a true compilation and generation of new binary is necessary or not, and if the content remains the same, ccache picks up the old cached binary instantly. CAUTION: the official ccache does not support -gsplit-dwarf. There is a hacked version to support -gsplit-dwarf. See https://bugzilla.samba.org/show_bug.cgi?id=10005 for details. You must use this hacked version to take advantage of -gsplit-dwarf. Guess who wrote the hacked version :-) The last two patches in the entries must be applied to the main ccache source tree since they are not merged yet. I should clean up these two patches so that they will make it to the official ccache repository, but I did not have much time this spring. Hope this helps. CI On 2015年04月25日 12:02, dliang wrote: > Thanks for your answer. > Maybe my PC is too slow, ^_^ > Beacuse I'm on the develop and debug, so I think I can't add options > "--disable-debug-symbols", I think I can build code in two dirctory, one for > code change without debug symbol, If error happen I debug on other dirctory, > but this will speed my develop down. > Now I'm trying to change moz.config file, to build mailnew into separate > shared library (libmail.so) which shouldn't link to libxul, Or first I > should change a faster computer. > Thanks for your answer again, I think my appreciation is more than words > that I can say! > > > 在 2015/4/25 1:31, Gregory Szorc 写道: >> libxul is the main library used by Gecko. It is possible to not compile >> it after changes by running `mach build <directory>` or `make -C >> <directory>`, but changes won't be visible in Thunderbird. i.e. this >> mode is only useful as a compilation check. >> >> If libxul takes 10-20 minutes to link, your system is likely running >> into hardware limitations (slow I/O, swapping, slow CPU, etc). You can >> try reducing the system requirements to build and link by disabling >> debug symbols. "ac_add_options --disable-debug-symbols" Of course, >> debugging won't be easy if you go this route. >> >> >> On Thu, Apr 23, 2015 at 7:07 PM, 梁栋 <liangdong1...@163.com >> <mailto:liangdong1...@163.com>> wrote: >> >> I'm an thunderbird developer, I develop in the source code comm-release. >> In the past, I had alredy download source code and finish compile, >> but the problem is: everytime I change the source code and in the >> recompile process, I will spend 10~20 >> minutes in linking libxul.so. >> After some search , I find we uesd to have an option >> --disable-libxul, but this options could not use now. >> I also try add options "ac_add_options --enable-static", >> "ac_add_options --with-ccache=/usr/bin/ccache" in .mozconfig, but >> nothing change! >> Is there any way to disable libxul.so to be compile or reduce >> recompile time? >> _______________________________________________ >> dev-builds mailing list >> dev-builds@lists.mozilla.org <mailto:dev-builds@lists.mozilla.org> >> https://lists.mozilla.org/listinfo/dev-builds >> _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
