'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 |