[swift-dev] Build Error: Relocation R_X86_64_PC32

[Ryan Lovelett]

On Mon, Mar 14, 2016, at 06:42 PM, Dmitri Gribenko wrote:
> On Mon, Mar 14, 2016 at 3:38 PM, Ryan Lovelett
> <swift-dev at ryan.lovelett.me> wrote:
> > On Tue, Mar 1, 2016, at 12:16 AM, Dmitri Gribenko wrote:
> >> IIRC there is no issue in the bug tracker, please feel free to file one!
> >>
> >> Also, if you are familiar with binutils internals, it might be helpful
> >> to bisect the linker.
> >
> > I'm finally getting around to bisecting binutils. I'm making some
> > progress but I'm getting hung up on one thing. The build script keeps
> > finding the "regular" linker at `/usr/bin/ld` instead of mine
> > `/tmp/binutils/2.25/usr/local/bin/ld`.
> >
> > I tried to update the PATH environment variable such that mine is before
> > `/usr/bin` but that doesn't seem to work. Is there an argument to send
> > that can force mine?
> 
> I'm afraid '/usr/bin/ld' is hardcoded in clang.  A few days ago Clang
> added a command-line option to override that:

Interesting learned something new.

> 
> commit 635bc7fefc12cc1333ba6ec77e563b7c8af01265
> Author: Peter Zotov <whitequark at whitequark.org>
> Date:   Wed Mar 9 05:18:16 2016 +0000
> 
>     Accept absolute paths in the -fuse-ld option.
> 
>     This patch extends the -fuse-ld option to accept a full path to an
> executable
>     and use it verbatim to invoke the linker. There are generally two
>     reasons
>     to desire this.
> 
>     The first reason relates to the sad truth is that Clang is
>     retargetable,
>     Binutils are not.
> 
>     While any Clang from a binary distribution is sufficient to compile
>     code
>     for a wide range of architectures and prefixed BFD linkers (e.g.
>     installed as /usr/bin/arm-none-linux-gnueabi-ld) as well as
>     cross-compiled
>     libc's (for non-bare-metal targets) are widely available, including
>     on all
>     Debian derivatives, it is impossible to use them together because
>     the -fuse-ld= option allows to specify neither a linker prefix nor
>     a full path to one.
> 
>     The second reason is linker development, both when porting existing
>     linkers
>     to new architectures and when working on a new linker such as LLD.
> 
>     Differential Revision: http://reviews.llvm.org/D17952
> 
>     git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262996
> 91177308-0d34-0410-b5e6-96231b3b80d8
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/