GoldLinking

Introducing GNU gold

Gold is a linker for ELF files. It was added to binutils March, 2008 and first released in binutils version 2.19. Gold is developed by Ian Lance Taylor and a small team at Google with participation of general GNU community. The motivation for writing gold was to make a linker that is faster than the GNU linker, especially for large applications coded in C++. Gold is known to work on x86 and x86-64, PowerPC (partially) and ARM. Gold is intended to link faster but may not support that much architectures as original GNU ld does however distributions, like Fedora, which primary supports GNU gold supported architectures may make it default linker in the future.

gold`s state in Fedora

GNU gold is in Fedora since binutils 2.19 release but was not built until recently. In binutils-2.20.51.0.2-7 (F-13/rawhide that time) we build gold as alternative linker to ld. Via /usr/sbin/alternatives we have /usr/bin/ld which is symbolic link to either /usr/bin/ld.bfd (original ld), or /usr/bin/ld.gold. By default /usr/bin/ld links to BFD ld but altering spec file is easily possible.

Before Fedora may uses gold as primary linker, several things have to be assured

• gold is stable and feature full, so linked apps generally work,
• gold is supported and available for Fedora-supported architectures,
• gold gives speed benefits, and
• Fedora application stack is capable of being linked by gold

gold-rebuild script

Basics

gold-rebuild is a Bash script which utilizes Mock, rpm-build, createrepo, yum and gold itself to rebuild, hence the name, Fedora packages or even whole comps groups and link resulted object files with gold instead of ld. For this purpose builds daily binutils CVS snapshot from trunk as part of Rawhide binutils SRPM and installs resulted new binutils packages to repository reachable by Mock. If rebuild of particular package fails it`s logged and failure is guess-classified to state what might be the problem.

General Capabilities

Usage: gold-rebuild [OPTION]...
Link programs with gold linker.

  -c, --color              Output in colors.
  -r, --rebuild            Rebuild current binutils snapshot,
                           create Yum for Mock repository and use it.
                           Without --rebuild we use distribution binutils.
  -g, --group <GROUP>      Select Fedora comps GROUP to rebuild.
  -p, --package <P1,...>   Comma separated list of packages to
                           rebuild. Mutual exclusive with '-g'.
  -t, --target <ARCH>      Target arch (e.g. i686 at x86_64 box).
  -o, --os-release <OS>    Fedora release from which to take
                           packages (e.g. 12, 13, ...).
  -h, --help               Display this help and exit.
  -v, --version            Output version information and exit.
  -q, --quiet              Be as quiet much as possible.
  -d, --debug              Be as verbose as possible.
Examples:
  gold-rebuild -c -r          Run with colors enabled as well as with
                              rebuild on.
  gold-rebuild                Run with defaults (colors=off, etc).

Report gold-rebuild bugs to mnowak@redhat.com
gold-rebuild home page: <http://mnowak.fedorapeople.org/gold-rebuild/>

Linear description of how-it-works

Code should be well commented so you shouldnt have much problems reading and understanding it

1. First we parse options and set several variables determining whether we are "quiet" or "verbose", building whole comps group or just several packages, etc.
2. If script is asked for rebuild of binutils from CVS, it
   1. Downloads latest binutils package from Koji and installs it on localhost
   2. Gets binutils.tar.bz2 and places it to RPM SOURCES/ directory
   3. Several necessary edits to Rawhides specfile is necessary - Version and Release fields are bumped to include snapshot date, recent upstream incorporated patches are turned off (one has to specify them in sources now...)
   4. SRPM package is built and we hand it to mock for rebuild
   5. binutils packages are built and placed into shiny new repository, createrepo is ran on it
   6. repository is added (if necessary) and enabled to be on for other packages when are being rebuilt
3. Selected SRPM packages for rebuild and linage by gold are downloaded to cache, dupes are removed
4. Logging facilities are being set
5. Script now iterates for every SRPM package
   1. Mock is asked to rebuild package $PK1
   2. Log is archived for later investigation
   3. If rebuild passed - good for us! - size of produced packages and time spent are logged, otherwise script investigates roots of the problem
      1. Last lines from log are being removed known to be bogus lines (such as ^ *user or ^ *group or ^make[[0-9]*]: [LE].*), actually last 15 lines are being inspected.
      2. Error classification.
   4. When error type is guessed, error message is written out
6. After all packages passed or failed to build'n'link statistics is produced (e.g. TOTAL: 99 PASS: 84 FAIL: 15)
7. As last step, all logs are archived

Classification looks like this

 err_component
   PKG    - problem in package
   LD     - problem in linker
   GCC    - problem in GCC
   FEDORA - e.g. we build i386-only package on PPC
 err_type
   $various