Skip to content

Added '-Blinker' frontend driver option for cross-linker search path #2483

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

karwa
Copy link
Contributor

@karwa karwa commented May 11, 2016

What's in this pull request?

Added a -Blinker fronted driver option. This works like clang/gcc's "-B" flag (which allows specifying an alternate toolchain location).

Currently, you can cross-compile with swift (assuming you've got a copy of the standard library compiled for the target), like so:
swiftc -target armv7-unknown-linux-gnueabihf -sdk ${sysroot} -resource-dir ${sdk-location} main.swift

However, this only works for modules (swiftmodules), not for executables. The host swift generates a link command to clang++ with -fuse-ld=gold, as it should, but there is currently no way to tell it where to find the gold cross-linker. Normally, you would put this information behind the '-B' switch, so we provide the same kind of functionality here.

Adding -Blinker ${gcc-toolchain-path} to the above command allows swift to cross-compile executables.


Before merging this pull request to apple/swift repository:

  • Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform Comment
All supported platforms @swift-ci Please smoke test
OS X platform @swift-ci Please smoke test OS X platform
Linux platform @swift-ci Please smoke test Linux platform

Validation Testing

Platform Comment
All supported platforms @swift-ci Please test
OS X platform @swift-ci Please test OS X platform
Linux platform @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

to be specified. This means swift can now cross-compile executables for
linux.
@jrose-apple
Copy link
Contributor

jrose-apple commented May 11, 2016

Thanks for looking at this! That's not a very Swifty flag name though (we don't really do the prefix thing), and I'm leery of adding Linux-only options. How is this flag used, i.e. what is ${gcc-toolchain-path}?

@lattner
Copy link
Contributor

lattner commented May 12, 2016

I think we should actually design the proper cross-toolchain solution as a real feature. That said, I don't think it is reasonable to block all progress on getting ports going on tackling such a large design topic. In the meantime, how about we carve out a namespace for "experimental" command line options and put them under that? @jrose-apple what do you think about that?

@karwa
Copy link
Contributor Author

karwa commented May 12, 2016

${gcc-toolchain-path} is the directory where ld.gold is (or whichever linker); It's the directory and not the exact path, because of the way it gets forwarded to clang.

I liked the name blinker, it's strange yet appropriate; we have -I and -L and -use-ld (with the equals and everything), Xlinker and so on, so I went for familiarity. I'm all for renaming, though; sticking this feature behind the "-B" flag isn't obvious, even for clang/gcc.

As for sticking it in an 'experimental' scope; this flag is basically the counterpart to -use-ld and as long as we have that flag allowing you to specify a linker, it is necessary to have a flag letting you specify where said linker lives. If we hide it away somewhere, we should do the same to -use-ld. FYI, I needed this right now in order to cross-compile LLDB (repl_swift produces an executable), so there is a imminent need for it.

I would support renaming both options, -use-ld should become -linker-name and -Blinker should become -linker-searchpath

@jrose-apple
Copy link
Contributor

Alternative: -use-ld actually takes a full path in recent Clangs, doesn't it? I'm not sure we've pulled that change into apple/swift-clang's "stable" branch yet, but that would be good enough to make progress, right?

@karwa
Copy link
Contributor Author

karwa commented May 12, 2016

Yes, I didn't know that, but you're right: http://reviews.llvm.org/rL262996

We haven't pulled that in, but it would be great if we did. I'd also want to rename -use-ld, because it is a bit legacy, but that's less important than having the functionality there.

@jrose-apple
Copy link
Contributor

It's already in the swift-3.0-branch for apple/swift-clang, so feel free to cherry-pick it into stable as well (via pull request).

@karwa
Copy link
Contributor Author

karwa commented May 18, 2016

This is no longer needed, absolute paths in clang is now in stable after the latest pull

@karwa karwa closed this May 18, 2016
@karwa karwa deleted the linker-search-path branch May 18, 2016 09:22
@karwa karwa restored the linker-search-path branch May 18, 2016 09:25
@karwa karwa mentioned this pull request Jun 6, 2016
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants