incremental linking?

[Claus Reinke]

Hi Hal,

> How did you get ghc to use gld when doing --make instead of standard
> ld?  I'm having the exact same problem you were and I'd love to make it
> work faster.

[Simon] might be worth adding to the docs (title: linking times on Suns, 
                Sun's ld vs GNU ld; explanation: see previous mails)?

ghc calls ld via gcc, so everything from the gcc man page about how gcc 
finds its tools seems to apply.

It could be as easy as setting PATH so that gnu's ld is found before sun's,
but as the message you quote said, the gcc installation might find the path
to sun's ld first by other routes.. 

> > (*) a little stumbling block here: gcc refers to PATH only *after* 
> >   perusing its preconfigured search paths. In our case, those included 
> >   /usr/ccs/bin, so we had to set GCC_EXEC_PREFIX instead (which 
> >   is used before the preconfigured paths).

So we had to do something like the following (assuming sh, and gnu's
binutils in /usr/local/packages):

    GCC_EXEC_PREFIX=/usr/local/packages/binutils/bin/ ghc-5.04 --make ..

The handling of prefixes is explained for gcc's -B option in the gcc man
page (here the version for our suns):

 -Bprefix
         This option specifies where to find the executables,
         libraries, include files, and data files of the compiler
         itself.

         The compiler driver program runs one or more of the
         subprograms cpp, cc1, as and ld.  It tries prefix as a
         prefix for each program it tries to run, both with and
         without machine/version/.

         For each subprogram to be run, the compiler driver first
         tries the -B prefix, if any.  If that name is not found,
         or if -B was not specified, the driver tries two
         standard prefixes, which are /usr/lib/gcc/ and
         /usr/local/lib/gcc-lib/.  If neither of those results in
         a file name that is found, the unmodified program name
         is searched for using the directories specified in your
         PATH environment variable.

         The compiler will check to see if the path provided by
         the -B refers to a directory, and if necessary it will
         add a directory separator character at the end of the
         path.

         -B prefixes that effectively specify directory names
         also apply to libraries in the linker, because the
         compiler translates these options into -L options for
         the linker.  They also apply to includes files in the
         preprocessor, because the compiler translates these
         options into -isystem options for the preprocessor.  In
         this case, the compiler appends include to the prefix.

         The run-time support file libgcc.a can also be searched
         for using the -B prefix, if needed.  If it is not found
         there, the two standard prefixes above are tried, and
         that is all.  The file is left out of the link if it is
         not found by those means.

         Another way to specify a prefix much like the -B prefix
         is to use the environment variable GCC_EXEC_PREFIX.

         As a special kludge, if the path provided by -B is
         [dir/]stageN/, where N is a number in the range 0 to 9,
         then it will be replaced by [dir/]include.  This is to
         help with boot-strapping the compiler.

To see where gcc is looking, check the "programs" entry in the output of

    gcc -print-search-dirs

and make sure your favourite ld is found first.

Cheers,
Claus