title: how to specify alternate linker command when linking with 'cc'
body: <p>When you use <code>cc(1)</code> to link a program, it will invoke a default linker command.  For instance, your version of the compiler may have been built to use /usr/bin/ld by default on a unix-like platform.</p>
  
  <p>Is there a way to specify a different linker command that <code>cc(1)</code> (or <code>c++(1)</code>) should use (e.g., <code>/usr/local/bin/ld</code> instead of <code>/usr/bin/ld</code>)?  I'm interested mostly in gcc and clang.</p>
  
  <p>I'm not looking for methods that involve running the various compilation steps separately (e.g., pre-process, compile, assemble, link).</p>
  
  <p>For example, I was hoping something like this might do the job:</p>
  
  <pre><code>env LD=/usr/local/bin/ld cc foo.c -o foo
  </code></pre>
  
  <p>But that doesn't work for gcc or clang.  It would work, of course, if you had a makefile that built an object file first, then invoked ${LD} to link (e.g., <code>env LD=/usr/local/bin/ld make</code>)</p>
  
  <p><strong>Update</strong> (with one possible motivation): To easily test with a different linker than the default linker.  For example, it would be nice to be able to do this:</p>
  
  <pre><code>cc --linker=/usr/local/bin/ld foo.c -o foo
  </code></pre>
  
  <p>Instead, you have to do generate the object file, run <code>cc -v</code> to figure out the arguments to <code>ld</code>, manually run the <code>ld</code> you want with those arguments:</p>
  
  <pre><code>cc -c foo.c
  cc -v foo.c -o /dev/null
  </code></pre>
  
  <p>Now look at the linker invocation and manually copy/paste replacing linker and temporary object file.  Something like this (example taken from a test on fedora 23) where you replace <code>/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/collect2</code> with <code>/usr/local/bin/ld</code> (although it's not <em>exactly</em> the same as <code>collect2</code>):</p>
  
  <pre><code>/usr/local/bin/ld -plugin /usr/libexec/gcc/x86_64-redhat-linux/5.3.1/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper -plugin-opt=-fresolution=/tmp/jhein/ccM2XKIg.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o c /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/5.3.1/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/5.3.1 -L/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../.. c.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/5.3.1/crtend.o /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/crtn.o
  </code></pre>
  
  <p>As you can see, that's not easy.  Note there is documentation in the gcc info page about how collect2 looks for a linker program.  But according to those docs, the first place it looks is not an environment variable or something you can specify on the command line (e.g., --linker).  The docs say it looks <em>first</em> for a "a hard coded linker file name".  If that documentation is correct, to coerce it not to use that linker (i.e., trick it), you would have to rename the default linker (e.g., <code>sudo mv /usr/bin/ld /usr/bin/ld.tmp-disable</code>).</p>
  
  <p><strong>Update 2</strong>: Using <code>-B</code> seems to work well enough for my needs.  See below where I posted an answer.  I can't accept my own answer, but I would if I could - it seems to solve the issue well.</p>