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
[SR-5783] SourceKit build fails on Fedora 24 #48353
Comments
Presumably, the file it's looking for is ./swift-corelibs-libdispatch/src/BlocksRuntime/Block.h, so I'm wondering if this is just missing an include path. |
My clang version: $ clang --version
clang version 3.8.0 (tags/RELEASE_380/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin Uname: $ uname -a
Linux localhost.localdomain 4.6.5-300.fc24.x86_64 #​1 SMP Thu Jul 28 01:10:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Swift revision: commit 5f9a50d65690412f65467c8903f427ff04dedc4f
Merge: c47b2fd 449cd98
Author: Jordan Rose <jordan_rose@apple.com>
Date: Mon Aug 28 14:11:04 2017 -0700
Merge pull request #​11504 from jrose-apple/access-level
Excise "Accessibility" from the compiler |
@alblue, any insights? |
Some systems have Block.h from Clang, but others have the Block.h separated out into a blocksruntime-dev or compiler-rt package. I think most of the time it comes from there ... In the Swift checkout, if you have compiler-rt alongside, then it should be used there for building: ./compiler-rt/lib/BlocksRuntime/Block.h However, it appears elsewhere as copies in the checkout as well: ./swift-corelibs-libdispatch/src/BlocksRuntime/Block.h ./lldb/include/lldb/Symbol/Block.h ./swift-corelibs-foundation/closure/Block.h There was some talk of trying to unify them; for example, @spevans removed a copy from Foundation a while back: |
FWIW, this is what I see in my checkout $ find . -name "Block.h"
./swift-corelibs-libdispatch/src/BlocksRuntime/Block.h
./compiler-rt/lib/BlocksRuntime/Block.h
./swift-corelibs-foundation/closure/Block.h
./lldb/include/lldb/Symbol/Block.h @alblue any ideas on how to debug this/which is the correct one to pick? I wonder how other systems get the correct header in this case. |
FWIW, this one is using a system clang (`3.8.0`) for linking, maybe it needs something else? |
With the following hack, I'm going to go one step close (which hints that a missing `include_dir` is the actual problem) diff --git a/tools/SourceKit/lib/Support/CMakeLists.txt b/tools/SourceKit/lib/Support/CMakeLists.txt
index 4ecd7b8..a7d36ca 100644
--- a/tools/SourceKit/lib/Support/CMakeLists.txt
+++ b/tools/SourceKit/lib/Support/CMakeLists.txt
@@ -1,3 +1,5 @@
+include_directories(/home/davide/work/swift/swift-corelibs-libdispatch/src/BlocksRuntime)
+
set(SourceKitSupport_sources
Concurrency-libdispatch.cpp
FuzzyStringMatcher.cpp But immediately after I hit another issue: FAILED: : && /usr/lib64/ccache/clang++ -Wno-unknown-warning-option -Werror=unguarded-availability-new -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics -Werror=switch -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -g -L/home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux -target x86_64-unknown-linux-gnu -lpthread -latomic -ldl -fuse-ld=gold tools/swift-reflection-dump/CMakeFiles/swift-reflection-dump.dir/swift-reflection-dump.cpp.o -o bin/swift-reflection-dump -L/home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/./lib -lswiftReflection /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMObject.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMSupport.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMBitReader.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMCore.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMBinaryFormat.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMMCParser.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMMC.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMSupport.a -lrt -ldl -ltinfo -lpthread -lz -lm /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMDemangle.a -Wl,-rpath,/home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/./lib && :
/home/davide/work/swift/swift/include/swift/Remote/MetadataReader.h:92: error: undefined reference to 'swift::Demangle::mangleNode(swift::Demangle::Node* const&)'
/home/davide/work/swift/swift/include/swift/Remote/MetadataReader.h:195: error: undefined reference to 'swift::Demangle::mangleNode(swift::Demangle::Node* const&)'
/home/davide/work/swift/swift/include/swift/Reflection/TypeRefBuilder.h:173: error: undefined reference to 'swift::Demangle::mangleNode(swift::Demangle::Node* const&)'
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) I wonder if this should become an umbrella bug 🙂 |
In case anybody is wondering, adding `LINK_LIBRARIES swiftDemangling` to the CMakelist.txt of `swift-reflection-dump` doesn't fix the problem, actually you get a bunch of duplicated symbols, i.e. *[6/51] Linking CXX executable bin/swift-reflection-dump
FAILED: : && /usr/lib64/ccache/clang++ -Wno-unknown-warning-option -Werror=unguarded-availability-new -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversi
on -fcolor-diagnostics -Werror=switch -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -g -L/home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux -target x86_64-unknown-linux-gnu -lpthread -latomic -ldl -fuse-ld=gold tools/swift-reflection-dump/CM
akeFiles/swift-reflection-dump.dir/swift-reflection-dump.cpp.o -o bin/swift-reflection-dump -L/home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/./lib lib/libswiftDemangling.a -lswiftReflection /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMObject.a /home/davide/work/swift/build/Ninja-DebugAsser
t/llvm-linux-x86_64/lib/libLLVMSupport.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMBitReader.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMCore.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMBinaryFormat.a /home/davide/work/swift/build/Ninja-
DebugAssert/llvm-linux-x86_64/lib/libLLVMMCParser.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMMC.a /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMSupport.a -lrt -ldl -ltinfo -lpthread -lz -lm /home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/lib/libLLVMDemangle
.a -Wl,-rpath,/home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/./lib && :
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Context.cpp.o): multiple definition of 'swift::Demangle::Context::isThunkSymbol(llvm::StringRef)'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Context.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Context.cpp.o): multiple definition of 'swift::Demangle::Context::demangleTypeAsNode(llvm::StringRef)'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Context.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Context.cpp.o): multiple definition of 'swift::Demangle::Context::demangleSymbolAsNode(llvm::StringRef)'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Context.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Context.cpp.o): multiple definition of 'swift::Demangle::Context::hasSwiftCallingConvention(llvm::StringRef)'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Context.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Context.cpp.o): multiple definition of 'swift::Demangle::Context::clear()'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Context.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Context.cpp.o): multiple definition of 'swift::Demangle::Context::Context()'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Context.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Context.cpp.o): multiple definition of 'swift::Demangle::Context::Context()'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Context.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Context.cpp.o): multiple definition of 'swift::Demangle::Context::~Context()'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Context.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Context.cpp.o): multiple definition of 'swift::Demangle::Context::~Context()'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Context.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(NodePrinter.cpp.o): multiple definition of 'swift::Demangle::DemanglerPrinter::operator<<(long long) &'
/usr/bin/ld.gold: lib/libswiftDemangling.a(NodePrinter.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(NodePrinter.cpp.o): multiple definition of 'swift::Demangle::DemanglerPrinter::operator<<(unsigned long long) &'
/usr/bin/ld.gold: lib/libswiftDemangling.a(NodePrinter.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Remangler.cpp.o): multiple definition of 'swift::Demangle::isSpecialized(swift::Demangle::Node*)'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Remangler.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(Remangler.cpp.o): multiple definition of 'swift::Demangle::getUnspecialized(swift::Demangle::Node*, swift::Demangle::NodeFactory&)'
/usr/bin/ld.gold: lib/libswiftDemangling.a(Remangler.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(ManglingUtils.cpp.o): multiple definition of 'swift::Mangle::isNonAscii(llvm::StringRef)'
/usr/bin/ld.gold: lib/libswiftDemangling.a(ManglingUtils.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(ManglingUtils.cpp.o): multiple definition of 'swift::Mangle::getStandardTypeSubst(llvm::StringRef)'
/usr/bin/ld.gold: lib/libswiftDemangling.a(ManglingUtils.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(ManglingUtils.cpp.o): multiple definition of 'swift::Mangle::needsPunycodeEncoding(llvm::StringRef)'
/usr/bin/ld.gold: lib/libswiftDemangling.a(ManglingUtils.cpp.o): previous definition here
/usr/bin/ld.gold: error: /home/davide/work/swift/build/Ninja-DebugAssert/swift-linux-x86_64/./lib/swift/linux/libswiftReflection.a(ManglingUtils.cpp.o): multiple definition of 'swift::Mangle::translateOperatorChar(char)'
/usr/bin/ld.gold: lib/libswiftDemangling.a(ManglingUtils.cpp.o): previous definition here I'm afraid this requires more knowledge about swift build than I have at this point in time. |
I found out the issue with this (documenting for posterity). The problem is that swift expects https://github.com/mackyle/blocksruntime to be available. This is also the reason why it works on ubuntu, as the dependencies list libblockruntime-dev. There's no such package for Fedora, officially, but building the whole thing is not the end of the world. In retrospective, this wasn't a particularly hard problem to work around, but it manifests in a fairly confusing way (as swift has several headers named `Block.h`, but the build system expects a system one). I guess a better way of handling this would be that of having the build system checking whether clang was built with blocks support (the host clang, that is), and if not, fail during the "configure" phase with an error asking to install libblocksruntime. This will be useful also as other distributions may have a similar problem (FWIW, blocksruntime is not a particularly famous package these days). So, I'm leaving this open until I find some time to implement this check in the build (or implement a similar solution, if somebody has alternative ideas). |
FWIW, a similar check was implemented for libbsd (as I didn't have on my system and I had to install afterwards, so, probably, this can be modeled after it). |
I would think that the 'compiler-rt' should be the canonical place to find the blocks runtime. I suspect the reason it exists in so many places is so that when checking out and building (for example) swift-corelibs-foundation that you don't need to also check out compiler-rt as well. I suspect the entry in lldb is an upstream copy from llvm which is duplicated in that part of the source tree, rather than anything Swift uses. |
FWIW, I tried on Ubuntu and if you don't install `libblocks-runtime-dev` separately, you end up with the same problem (missing header). |
We build and package blocks runtime as part of dispatch now. |
Additional Detail from JIRA
md5: a9652be0dbe8d18e5b93d6d7e5043bf9
Issue Description:
While trying to revamp FreeBSD support for swift, I fired up a Fedora VM to compare the two builds.
I found out that the out-the-box Debug+Assertions build of swift fails trying to build Concurrency-libdispatch.cpp
The text was updated successfully, but these errors were encountered: