-pie linker argument on Linux about rules_swift

[keith]

It looks like SwiftPM hard codes always passing -fPic on Linux (and not on macOS since it's the default) https://github.com/apple/swift-package-manager/blob/b8d4c97579cfb6eec7a383e26e4dc855b693c61f/Sources/Workspace/Destination.swift#L128

[allevato]

It hasn't affected us internally yet because AFAICT our CROSSTOOL passes -pie by default, and rules_swift's linking merely piggy-backs off the C++ executable linking behavior there.

That being said, Joe Groff says that "PIE is a functional necessity for linking Swift executables correctly", so perhaps we should be passing it unconditionally anyway. I dug around and it's not clear why it's required and why it affects the behavior you saw above, but judging by where the crash occurred in that backtrace, maybe PIC/PIE has some effect on how protocol witnesses are looked up.

One concern I have is, if you have a Swift binary that also links in C++ code, do the archives I get from the cc_library targets have code compiled with -fPIC, since I don't think non-PIC objects will work correctly in a PIE. Presumably if we're already linking PIEs internally then that should be working correctly now, but I want to double-check a few things.

[keith]

I've submitted #99 to fix this if there's no objection

[keith]

The linker flags in my PR shouldn't get propagated to the cc_library right? But actually if PIE is required for Swift, maybe that's desired anyways?

[allevato]

No, nothing would get propagated down the dependency tree. My concern is the opposite direction—whether anything needs to be done to ensure that .o files from cc_libraries used upstream are compiled with PIC enabled so that they can be linked into a PIE.

[keith]

Ah. At least that that point I think it would fail to link? Or at least warn?