Hello there. I've been trying to build SourceKit-LSP on Linux, but I consistently encounter an error with Clang 7.0. I've tried using multiple versions of the Swift toolchain from the Nov. 01 release and onward with little success. I should also mention I am working on Arch Linux, so my toolchain is derived from a slightly patched version of the Ubuntu 16.04/18.04 (I've tried both) binaries.
An excerpt from the swift build -Xcxx -I/usr/lib/swift -v command:
lsb_release -r
which clang
[...]
/usr/bin/clang -target x86_64-unknown-linux --sysroot / -fPIC -g -O0 -DSWIFT_PACKAGE=1 -DDEBUG=1 -fblocks -fmodules -fmodule-name=libllbuild -I /home/aemino/dev/sourcekit-lsp/.build/checkouts/swift-llbuild-0f2964f9/products/libllbuild/include -I /home/aemino/dev/sourcekit-lsp/.build/checkouts/swift-llbuild-0f2964f9/lib/BuildSystem/include -I /home/aemino/dev/sourcekit-lsp/.build/checkouts/swift-llbuild-0f2964f9/lib/Core/include -I /home/aemino/dev/sourcekit-lsp/.build/checkouts/swift-llbuild-0f2964f9/lib/Basic/include -I /home/aemino/dev/sourcekit-lsp/.build/checkouts/swift-llbuild-0f2964f9/lib/llvm/Support/include -fmodules-cache-path=/home/aemino/dev/sourcekit-lsp/.build/x86_64-unknown-linux/debug/ModuleCache -I/usr/lib/swift -MD -MT dependencies -MF /home/aemino/dev/sourcekit-lsp/.build/x86_64-unknown-linux/debug/libllbuild.build/C-API.cpp.d -std=c++14 -c /home/aemino/dev/sourcekit-lsp/.build/checkouts/swift-llbuild-0f2964f9/products/libllbuild/C-API.cpp -o /home/aemino/dev/sourcekit-lsp/.build/x86_64-unknown-linux/debug/libllbuild.build/C-API.cpp.o
/usr/bin/clang -target x86_64-unknown-linux --sysroot / -fPIC -g -O0 -DSWIFT_PACKAGE=1 -DDEBUG=1 -fblocks -fmodules -fmodule-name=LLVMSupport -I /home/aemino/dev/sourcekit-lsp/.build/checkouts/indexstore-db-b33c78d7/lib/LLVMSupport/include -fmodules-cache-path=/home/aemino/dev/sourcekit-lsp/.build/x86_64-unknown-linux/debug/ModuleCache -I/usr/lib/swift -MD -MT dependencies -MF /home/aemino/dev/sourcekit-lsp/.build/x86_64-unknown-linux/debug/LLVMSupport.build/Support/raw_ostream.cpp.d -std=c++14 -c /home/aemino/dev/sourcekit-lsp/.build/checkouts/indexstore-db-b33c78d7/lib/LLVMSupport/Support/raw_ostream.cpp -o /home/aemino/dev/sourcekit-lsp/.build/x86_64-unknown-linux/debug/LLVMSupport.build/Support/raw_ostream.cpp.o
fatal error
:
error in backend: invalid llvm.linker.options
clang-7: error
: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 7.0.0 (tags/RELEASE_700/final)
Target: x86_64-unknown-linux
Thread model: posix
InstalledDir: /usr/bin
clang-7: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script.
clang-7: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-7: note: diagnostic msg: /tmp/C-API-15ec21.cpp
clang-7: note: diagnostic msg: /tmp/C-API-15ec21.cache
clang-7: note: diagnostic msg: /tmp/C-API-15ec21.sh
clang-7: note: diagnostic msg:
********************
Please let me know if I can provide any other information. Thanks!
Newer Clang has a problem with using -fmodules and module auto-linking on linux. Using -fmodules for the C++ code is not necessary but SwiftPM passes the flags unconditionally.
To workaround this set this env var for the build invocation:
env CCC_OVERRIDE_OPTIONS="#x-fmodules s/-fmodules-cache-path.*//" swift build <...>
this will remove the module options from the clang invocations
I haven't seen this, did you try everything from scratch ?
I don't think it's the clang invocation that you posted that emits this error, look for other invocations happening before and run them in the command-line to make sure. Once you are certain you found the invocation with such an error, add -v to see the underlying command.
@akyrtzi, thanks, I'll look into that. There was far too much push back on using the existing format that I wanted (that is, I wanted it to be the linker options embedded as they are currently), and Rui and others felt that splitting it up was better.
Wanted to provide an update--it seems that the issues I was having stemmed from the usage of the Ubuntu toolchain (which I had rather crudely patched for Arch Linux.)
I finally managed to build the toolchain from master, and I successfully compiled SourceKit-LSP.
On Fedora 29 with a master checkout of Swift as of 2018-12-30, I needed
env CCC_OVERRIDE_OPTIONS="#x-fmodules s/-fmodules-cache-path.*//" swift build -Xcxx -I/$HOME/Projects/Develop/swift-source/swift-corelibs-libdispatch -Xcxx -I$HOME/Projects/Develop/swift-source/compiler-rt/lib/BlocksRuntime/
To get SourceKit-LSP built. SOURCEKIT_TOOLCHAIN_PATH=$HOME/Projects/Develop/swift-toolchain also set.
Well I'm trying to build LSP on Arch Linux, which is a kind of minefield for installing and building Snapshots. I managed to build the latest Swift 5 snapshot and install into ~/.swiftenv/versions/ folder. Great.
But building LSP is a pretty hard. First of all, Arch Linux has the latest clang and co. 7.x.
[segabor@csihuhu sourcekit-lsp]$ swift build
clang-7: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-unknown-linux
Thread model: posix
InstalledDir: /usr/bin
clang-7: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script.
clang-7: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-7: note: diagnostic msg: /tmp/C-API-b83bcc.cpp
clang-7: note: diagnostic msg: /tmp/C-API-b83bcc.cache
clang-7: note: diagnostic msg: /tmp/C-API-b83bcc.sh
clang-7: note: diagnostic msg:
********************
[segabor@csihuhu sourcekit-lsp]$ swift -version
Swift version 5.0-dev (LLVM f63b283c71, Clang 41ac4c4262, Swift 3e09c4a21f)
Target: x86_64-unknown-linux-gnu
[segabor@csihuhu sourcekit-lsp]$
UPDATE: I finally managed to build the whole stuff with the following command:
Sorry for the delay, I'm trying to cover too many items. SVN r350476 should address this. I'll put up a PR for clang to backport this to the 5.0 release.
