swift driver on Darwin


(Jordan Rose) #1

[+swift-dev, swift-build-dev] Once upon a time I think I had the idea that swiftc should be useful independent of having a Clang install, but we've long since given up on that on Linux and it's not such an interesting configuration on Darwin. I don't have strong objections to merging them, though there might be some trickiness around picking the right profiling libraries (if Swift and Clang are ever out of sync we would ideally prefer Swift's).

The other thing floating around here is something Daniel Dunbar once brought up: usually each compiler wants to own the linker invocation, but then you have a hard time linking object files from multiple compilers using the same linker invocation. (Consider linking with clang vs. clang++, and then needing to add custom arguments for Swift.) It would be nice™ if instead a build system could ask "what additional linker flags do you need before/after your object files?", and put that in as necessary.

Jordan

···

On Dec 17, 2016, at 21:51, Saleem Abdulrasool <compnerd@compnerd.org> wrote:

Hey,

I was poking at the swift driver today and noticed something in there. Seems like it directly invokes the linker, yet has a comment about possibly using clang to avoid duplicating a bunch of logic.

Im thinking of duplicating some of the driver logic for linking for Windows and cross-Windows (which becomes much more interesting as I can't see a good way to handle that via clang atm). Flavoring makes it hard (GNU vs link style arguments which arent a direct translation) to use clang.

However, I was wondering if there is a reason to not just re-use clang for the link on Darwin since there is no flavoring of the linker here AFAIK.

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org


(Joe Groff) #2

Could something like the autolinking mechanism be used to pull in necessary runtime object files, such as the swift_begin/end.o stubs, without direct help from the driver?

-Joe

···

On Dec 19, 2016, at 10:23 AM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:

[+swift-dev, swift-build-dev] Once upon a time I think I had the idea that swiftc should be useful independent of having a Clang install, but we've long since given up on that on Linux and it's not such an interesting configuration on Darwin. I don't have strong objections to merging them, though there might be some trickiness around picking the right profiling libraries (if Swift and Clang are ever out of sync we would ideally prefer Swift's).

The other thing floating around here is something Daniel Dunbar once brought up: usually each compiler wants to own the linker invocation, but then you have a hard time linking object files from multiple compilers using the same linker invocation. (Consider linking with clang vs. clang++, and then needing to add custom arguments for Swift.) It would be nice™ if instead a build system could ask "what additional linker flags do you need before/after your object files?", and put that in as necessary.


(Jordan Rose) #3

I'm not sure, but it's probably very linker-dependent, since we actually need the bracketing. This also applies to non-autolinking things like, say, enabling or disabling dead code stripping, but those flags can usually appear anywhere in the list.

Jordan

···

On Dec 21, 2016, at 11:11, Joe Groff <jgroff@apple.com> wrote:

On Dec 19, 2016, at 10:23 AM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:

[+swift-dev, swift-build-dev] Once upon a time I think I had the idea that swiftc should be useful independent of having a Clang install, but we've long since given up on that on Linux and it's not such an interesting configuration on Darwin. I don't have strong objections to merging them, though there might be some trickiness around picking the right profiling libraries (if Swift and Clang are ever out of sync we would ideally prefer Swift's).

The other thing floating around here is something Daniel Dunbar once brought up: usually each compiler wants to own the linker invocation, but then you have a hard time linking object files from multiple compilers using the same linker invocation. (Consider linking with clang vs. clang++, and then needing to add custom arguments for Swift.) It would be nice™ if instead a build system could ask "what additional linker flags do you need before/after your object files?", and put that in as necessary.

Could something like the autolinking mechanism be used to pull in necessary runtime object files, such as the swift_begin/end.o stubs, without direct help from the driver?