On 2015年04月30日 10:51, dliang wrote: > actullay, now in mozilla build system, gold-ld is the default linker if your > OS has already exist gold-ld, follow is codes copy from mozilla/configure, > (my code version is tb-beta 34-b1): > > 10029 if test "$GNU_CC" -a -n "$MOZ_FORCE_GOLD"; then > 10030 if $CC -Wl,--version 2>&1 | grep -q "GNU ld"; then > 10031 GOLD=$($CC -print-prog-name=ld.gold) > 10032 case "$GOLD" in > 10033 /*) > 10034 ;; > 10035 *) > 10036 GOLD=$(which $GOLD) > 10037 ;; > 10038 esac > 10039 if test -n "$GOLD"; then > 10040 mkdir -p $_objdir/build/unix/gold > 10041 rm -f $_objdir/build/unix/gold/ld > 10042 ln -s "$GOLD" $_objdir/build/unix/gold/ld > 10043 if $CC -B $_objdir/build/unix/gold -Wl,--version 2>&1 | > grep -q "GNU gold"; then > 10044 LDFLAGS="$LDFLAGS -B $_objdir/build/unix/gold" > 10045 else > 10046 rm -rf $_objdir/build/unix/gold > 10047 fi > 10048 fi > 10049 fi > 10050 fi > > On 2015年04月29日 07:07, Mike Hommey wrote: >> On Tue, Apr 28, 2015 at 05:24:16PM -0500, Joshua Cranmer ? wrote: >>> On 4/28/2015 4:28 PM, ISHIKAWA, Chiaki wrote: >>>> On 2015/04/28 23:30, Toan Pham wrote: >>>>> Linking is a process of resolving symbols from object files with >>>>> external libraries, and it should not take that long. When you have a >>>>> chance, try to compile the project under a ram filesystem like tmpfs. >>>>> I use it most of the time, even when I have an SSD drive. The tmpfs >>>>> will speed up compilation significantly. >>>>> >>>> >>>> With full debug build of thunderbird (without -gsplit-dwarf), I think >>>> libxul.so becomes close to 1GB in size. >>>> So creating it puts much workload in terms of I/O, and >>>> in terms of memory pressure, too, since ordinary linker's data structure >>>> to handle the large number of symbols simply runs out of 32-bit memory >>>> space during linking. >>>> >>>> Currently with -gsplit-dwarf,libxul. it is 357.2MB. It is rather large. >>>> >>>> I may want to try to set aside 2GB of RAM to tmpfs given this size of >>>> libxul.so, but as of now, linking libxul runs in a reasonable time by >>>> using GNU gold linker and -gsplit-dwarf option to GCC. >>>> >>>> Thank you for the suggestion, if something goes wrong with >>>> linking/build I may try to create a large tmpfs using RAM. >>>> >>>> At the same time, I have to report that I monitor the memory usage during >>>> build, and saw most of memory is used as cache/buffer during linking. >>>> Hence I am not sure if tmpfs based on RAM will bring about much speedup in >>>> my environment. My CPU is probably 1 ~ 1.5 generation behind the latest >>>> one. That may explain the slow speed. >>> >>> Linking effectively requires building a list of used files, concatenating >>> the used sections together, dropping redundant COMDATs, and then patching >>> offsets into the binary, which requires scanning all of the .o files at >>> least once--the key, then, is to make sure that the scanning process never >>> touches disk. In other words, you need enough RAM that the .o files stay >>> resident in the file system cache from when they were last touched in a >>> compile-edit-rebuild cycle. Outside of ensuring you have at least 8GB of RAM >>> [1], the only recommendation I can give for speeding up is using split-dwarf >>> (removes the ginormous debug information from the linking equation) and >>> using gold, at least on Linux. I don't think ramfs style builds speed up >>> builds if the filesystem is already resident in cache. >> >> (note gold is the default for local builds) >>
Dear Liang, I am not entirely sure if configure in my environment picks up GNU gold automatically. Actually I create a ~/bin/ld shell script that invokes GNU gold linker explicitly. and put my ~/bin near the beginning of PATH environment variable before /usr/bin so that "ld" noticed by configure is always my ~/bin/ld and invokes GNU gold no matter what the symlink from /usr/bin/ld is. (And this trick is useful for OTHER programs that don't look for GNU gold seriously in its configure script.) You might want to check that your GNU gold on your computer under whatever filename is *IS* invoked during the build of TB. (I suppose major linux distribution installs GNU gold linker as ld.gold by default. But you may want to check just in case. What distribution of linux do you use assuming you use linux?) If you link time is still in 10-20 minutes range using GNU gold linker, you might want to increase RAM. How much RAM do you have in your computer? I think 8GB is bare minimum for comfortable linking. (I am assuming that you use 64-bit OS.) Also, what is your CPU? I am just curious. With four cores allocated to a virtual machine, my build time is not that bad after a modification of several files including the not-so-long link time (don't forget -gsplit-dwarf to CC option.) and this is inside VirtualBox. If you have a few disk drives, try spreading the source files in one disk, the object tree in other disk, etc. on different I/O channels (i.e., not multiplexing them on one bus) if possible although this is easier said than done when your disks are almost full already. Also, try using the fastest disk for object files. [you may need experimenting here.] That is all I can think of speeding up link time significantly. CI _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
