I'm being hit by the problem where the wrong linker is being invoked
when trying to build a program with swiftc for Android.
The problem seems to already be known and reported here, but the
solutions/workarounds don't fully work for me: https://bugs.swift.org/browse/SR-1264
The only way I can make this work is by removing/renaming my system
installed /usr/bin/ld.gold so the process can't find it.
- Changing my PATH so another ld.gold is found first didn't affect
things. It looks like it always prefers /usr/bin/ld.gold.
- Adding the symlink for /usr/bin/armv7-none-linux-androideabi-ld.gold
didn't help (until I removed my /usr/bin/ld.gold
- Using the -use-ld= switch seemed to have absolutely no effect for
me. (I tried multiple things like armv7 to find an ld.armv7 and also
tried full explicit paths to the real android ld.gold)
Any ideas on how to fix this? I don't like having to remove my system ld.gold.
As for me, I've found success with the symlink solution up until now. I'm
not sure why it doesn't work in your case...
I believe that in later versions of Clang, -fuse-ld accepts full paths to
linkers. So it may work if you have a sufficiently recent version --
although I haven't tried myself.
- Brian Gesiak
···
On Sat, Sep 24, 2016 at 8:26 PM, Eric Wing via swift-dev < swift-dev@swift.org> wrote:
I'm being hit by the problem where the wrong linker is being invoked
when trying to build a program with swiftc for Android.
The only way I can make this work is by removing/renaming my system
installed /usr/bin/ld.gold so the process can't find it.
- Changing my PATH so another ld.gold is found first didn't affect
things. It looks like it always prefers /usr/bin/ld.gold.
- Adding the symlink for /usr/bin/armv7-none-linux-androideabi-ld.gold
didn't help (until I removed my /usr/bin/ld.gold
- Using the -use-ld= switch seemed to have absolutely no effect for
me. (I tried multiple things like armv7 to find an ld.armv7 and also
tried full explicit paths to the real android ld.gold)
Any ideas on how to fix this? I don't like having to remove my system
ld.gold.
I also played with -fuse-ld:
I'm invoking swiftc, whicn in turn invokes -fuse-ld behind the scenes.
I didn't try a full path, but I did try renaming the ld tool to
arm-linux-androideabi-ld.gold with the swiftc flag -use-ld. But that
seemed to confuse the process. I'm not sure why. But once I saw there
was a file called ld.gold in a different ndk directory, the
-tools-directory was all I needed.
Thanks,
Eric
···
On 9/25/16, Brian Gesiak <modocache@gmail.com> wrote:
As for me, I've found success with the symlink solution up until now. I'm
not sure why it doesn't work in your case...
I believe that in later versions of Clang, -fuse-ld accepts full paths to
linkers. So it may work if you have a sufficiently recent version --
although I haven't tried myself.
- Brian Gesiak
On Sat, Sep 24, 2016 at 8:26 PM, Eric Wing via swift-dev < > swift-dev@swift.org> wrote:
I'm being hit by the problem where the wrong linker is being invoked
when trying to build a program with swiftc for Android.
The only way I can make this work is by removing/renaming my system
installed /usr/bin/ld.gold so the process can't find it.
- Changing my PATH so another ld.gold is found first didn't affect
things. It looks like it always prefers /usr/bin/ld.gold.
- Adding the symlink for /usr/bin/armv7-none-linux-androideabi-ld.gold
didn't help (until I removed my /usr/bin/ld.gold
- Using the -use-ld= switch seemed to have absolutely no effect for
me. (I tried multiple things like armv7 to find an ld.armv7 and also
tried full explicit paths to the real android ld.gold)
Any ideas on how to fix this? I don't like having to remove my system
ld.gold.