'How to configure a non-standard linker for an autotooled build?

I wanted to configure an autotooled project to invoke a non-standard linker (the gold linker), using the stock autotools of Linux Mint 16/Ubuntu 13.10

I believed I would achieve this by:

  • libtoolize-ing the project
  • Running ./configure LD=/path/to/my/linker ... etc.

However this has been ineffective. libtoolize has been successful. After a standard ./configure; make I now see that libtool is doing the linking:

/bin/bash ./libtool  --tag=CXX   --mode=link g++  -g -O2    -o helloworld helloworld.o

But passing LD=/path/to/my/linker to configure makes no difference. Experimentally, I even ran:

./configure LD=/does/not/exist

expecting to provoke an error, but I didn't. The output contains:

checking if the linker (/does/not/exist -m elf_x86_64) is GNU ld... no
checking whether the g++ linker (/does/not/exist -m elf_x86_64) supports shared libraries... yes

And thereafter a make continues to link, successfully, invoking g++ exactly as before.

What is the right way to configure a non-standard linker?



Solution 1:[1]

But passing LD=/path/to/my/linker to configure makes no difference

This is because LD is almost never and should almost never be used to link any user-space program. Correct links are performed by using the appropriate compiler driver (gcc, g++, etc) instead.

What is the right way to configure a non-standard linker?

If you have /some/path/ld and you want gcc to use that ld, pass -B/some/path flag to gcc.

It then follows that you likely want:

./configure CC='gcc -B/some/path' CXX='g++ -B/some/path' ...

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Employed Russian