[SR-1] Linux: remove Swift dependence on the swift.ld linker script #42627
Comments
|
Have you opened a binutils bug for this issue? |
On Linux the following patch works fine, when gold is the default linker:
diff --git a/lib/Driver/ToolChains.cpp b/lib/Driver/ToolChains.cpp
index 712ea6581652..df4f2919de46 100644
--- a/lib/Driver/ToolChains.cpp
+++ b/lib/Driver/ToolChains.cpp
@@ -1096,6 +1096,7 @@ toolchains::GenericUnix::constructInvocation(const LinkJobAction &job,
// FIXME: We probably shouldn't be adding an rpath here unless we know ahead
// of time the standard library won't be copied.
+ Arguments.push_back("-fuse-ld=bfd");
Arguments.push_back("-Xlinker");
Arguments.push_back("-rpath");
Arguments.push_back("-Xlinker"); |
|
Sorry for the late response. I need to catch up on where this stands now. > Cary Coutant normally fixes such issues quickly. Are you suggesting that Cary can add support for linker scripts to the gold linker? We were really only using the linker script to simplify creating a table the aggregates all the protocol conformance data, so the feature we are using from the standard linker is relatively simple. I've heard we might not be doing that any more, so this might all be moot. If we were mandating the gold linker, then your patch is fine. If not, we'd need to pass along the intent to use the gold linker flag through swiftc (either by any existing linker flag pass-through support, or by enabling a new option). This is going to become more critical as we try to move to Ubuntu 16.04, where I'm hitting linker relocation issues using the standard linker. |
|
(I should add this was a bug I filed to track this item in our pre-launch system and Joe was kind enough to reflect it into the public system once we got this up and running, hence my interest here). |
|
> Are you suggesting that Cary can add support for linker scripts to the gold linker? Ignore - I followed the thread of what you filed over there. We're on the same page. Yes, I saw the original bug that was duped to as I was originally looking to see if we could use the same approach for the gold linker that we use for the standard linker. The bug it was duped to was filed a couple years ago. |
|
I just noticed this bug. Doesn't this #1157 fix it? |
|
The alternate approach too has been replaced with another solution that avoids the wrapping entirely. There are no linker scripts in the build now I believe. |
Additional Detail from JIRA
md5: 90c6fa571fac13d05c95850bed417233
Issue Description:
Building Swift on Linux currently depends on a linker script to mark protocol conformances. This linker script method is not compatible with the gold linker. We want to support using the gold linker, so come up with another method to achieve this that is compatible with the gold linker.
It seems likely there are at least the following options that seem potentially valid:
We could do some work inside the swift compiler itself as a pre-link step, to collate the protocol conformance data into a single object file. I think we’re ultimately looking for a section of data that we know the size and length of, that contains the conformance data, that can be accessed as a known symbol name at runtime.
Adjust the gold linker to support the symbol collation functionality in ld.bfd that is not in ld.gold. The gold linker is a GPLv3 project.
The text was updated successfully, but these errors were encountered: