Can you provide example error (or whatever indicates the wrong linker) output? It'll help me hone in on the area to attack.

Comment by Ryan Lovelett (JIRA)

swiftpm: using gold linker
+ /home/ryan/Source/swiftpm/Utilities/bootstrap -v --swiftc=/home/ryan/Source/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swiftc --sbt=/home/ryan/Source/build/Ninja-ReleaseAssert/llbuild-linux-x86_64/bin/swift-build-tool --build=/home/ryan/Source/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64
bootstrap: note: building stage1: /home/ryan/Source/build/Ninja-ReleaseAssert/llbuild-linux-x86_64/bin/swift-build-tool -f /home/ryan/Source/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/.bootstrap/build.swift-build -v
/usr/bin/ld: /home/ryan/Source/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/.bootstrap/lib/PackageDescription.a(Package.o): relocation R_X86_64_PC32 against protected symbol `_TMLCC18PackageDescription7Package10Dependency' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation)
Traceback (most recent call last):
File "/home/ryan/Source/swiftpm/Utilities/bootstrap", line 640, in <module>
 main()
File "/home/ryan/Source/swiftpm/Utilities/bootstrap", line 541, in main
 sandbox_path, args, bootstrap=True)
File "/home/ryan/Source/swiftpm/Utilities/bootstrap", line 413, in process_runtime_libraries
 subprocess.check_call(cmd)
File "/usr/lib/python3.5/subprocess.py", line 584, in check_call
 raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/lib/hardening-wrapper/bin/clang++', '/home/ryan/Source/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/linux/x86_64/swift_begin.o', '-shared', '-Xlinker', '--whole-archive', '-Xlinker', '/home/ryan/Source/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/.bootstrap/lib/PackageDescription.a', '-Xlinker', '--no-whole-archive', '-Xlinker', '-rpath=$ORIGIN/../linux', '-lswiftGlibc', '-L', '/home/ryan/Source/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/linux', '--target=x86_64-unknown-linux-gnu', '-Xlinker', '-rpath', '-Xlinker', '/home/ryan/Source/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/linux', '-lswiftCore', '/home/ryan/Source/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/linux/x86_64/swift_end.o', '-o', '/home/ryan/Source/build/Ninja-ReleaseAssert/swiftpm-linux-x86_64/.bootstrap/lib/swift/pm/libPackageDescription.so']' returned non-zero exit status 1
utils/build-script: command terminated with a non-zero exit status 1, aborting

I can provide the full build output if you need more but I think this is the germane part.

@belkadan what is your take here?

Actually maybe this is all under my control. Since this is in stage 1 of the bootstrap.

Yeah, I'm inclined to think --use-gold-linker should apply to everything build-script tries to build, or at least all the binaries on the "host" platform for a cross-compile.

I added the logic to respect the gold setting in Foundation. If I remember correctly, the passing of this flag was a bit haphazard to the different projects. On arm, this isn't noticed because swiftc defaults to gold once it's responsible for the process.

In Foundation, I set a SWIFT_USE_LINKER="-fuse-ld=gold" env variable. We could set this for swiftpm as well, and pick it up in the bootstrap script.

You can try adding: `-Xcc -fuse-ld=gold` in the bootstrap script where we do the other such things. If that works, that's the PR (well including a ld setting which then needs to go into the swift build-script too).

Do you think this should also cause swiftpm to use gold in all subsequent operations (self-hosted, and client builds)?

I'm not sure I can say, let's do the minimum initially and see if the tests pass.

The story behind the gold linker flag support I initially added was that the swift compiler, when it links, couldn't yet use the gold linker (SR-1 ;-) ) since it used a gold-incompatible linker script to collect protocol conformance data. SR-1 was intended to be implemented by somebody at some point (I haven't yet had the cycles to look at it, although somebody (Joe Groff maybe?) mentioned he thought we no longer use the linker script). In any event, since the swiftc-built executables, including parts of the stdlib, couldn't use the gold linker, for the swift part of build-script-impl I had to indicate "use the gold linker for the C++ parts, but don't use it for the Swift-compiled linkage." This is where the initial incongruous handling of the gold linker flag started.

There may be other parts of the build that came online after I did the gold linker support that didn't catch what I was doing, and may not have wired up their C++ parts to link with the intended linker.

I'll have a look at all of this at some point, as this may end up being a blocker for getting Ubuntu 16.04 handled. (Or we need to address the relocation error we're getting from the standard linker).

I'm fairly certain that I fixed SR-1 a while back. apple/swift#1157

I didn't know about the bug, so I didn't close it at the time (though I just commented on it to make sure that it does). This should no longer be an impediment to cleaning up the handling of gold in other parts of the project.

Comment by Ryan Lovelett (JIRA)

As far as I can tell in my tests apple/swift#2609 has fixed this issue.

@trfiala it should now be possible to build on Ubuntu 16.04.

I'm going to leave this open for a little bit for someone else to confirm.

Thanks for the heads up, Ryan.

I'll look to get the Ubuntu 16.04 process moving along after I verify I can work there and get any other issues identified.

I think this has effectively been resolved by 2609, please reopen if not.