Skip to content
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

Closed
dcci mannequin opened this issue Aug 28, 2017 · 13 comments
Closed

[SR-5783] SourceKit build fails on Fedora 24 #48353

dcci mannequin opened this issue Aug 28, 2017 · 13 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. Fedora Platform: Fedora

Comments

@dcci
Copy link
Mannequin

dcci mannequin commented Aug 28, 2017

Previous ID SR-5783
Radar None
Original Reporter @dcci
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Source Tooling
Labels Bug, Fedora
Assignee None
Priority Medium

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

[31/173] Building CXX object tools/SourceKit/lib/Support/CMakeFiles/SourceKitSupport.dir/Concurrency-libdispatch.cpp.o
FAILED: /usr/lib64/ccache/clang++   -DCMARK_STATIC_DEFINE -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/SourceKit/lib/Support -I/home/davide/work/swift/swift/tools/SourceKit/lib/Support -I/home/davide/work/swift/swift/tools/SourceKit/include -Iinclude -I/home/d
avide/work/swift/swift/include -I/home/davide/work/swift/llvm/include -I/home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/include -I/home/davide/work/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/tools/clang/include -I/home/davide/work/swift/llvm/tools/clang/include -I/home/davide/work/swift/cmark/src
-I/home/davide/work/swift/build/Ninja-DebugAssert/cmark-linux-x86_64/src -I/home/davide/work/swift/swift-corelibs-libdispatch -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    -fno-exceptions -fno-rtti -target x86_64-unknown-linux-gnu
-O0 -g -UNDEBUG -fblocks -MMD -MT tools/SourceKit/lib/Support/CMakeFiles/SourceKitSupport.dir/Concurrency-libdispatch.cpp.o -MF tools/SourceKit/lib/Support/CMakeFiles/SourceKitSupport.dir/Concurrency-libdispatch.cpp.o.d -o tools/SourceKit/lib/Support/CMakeFiles/SourceKitSupport.dir/Concurrency-libdispatch.cpp.o -c /home
/davide/work/swift/swift/tools/SourceKit/lib/Support/Concurrency-libdispatch.cpp
/home/davide/work/swift/swift/tools/SourceKit/lib/Support/Concurrency-libdispatch.cpp:20:10: fatal error: 'Block.h' file not found
#include <Block.h>
         ^
1 error generated.
@dcci
Copy link
Mannequin Author

dcci mannequin commented Aug 28, 2017

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.
(Although I'm curious to understand how it worked before).

@dcci
Copy link
Mannequin Author

dcci mannequin commented Aug 28, 2017

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 #&#8203;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 #&#8203;11504 from jrose-apple/access-level

    Excise "Accessibility" from the compiler

@belkadan
Copy link
Contributor

@alblue, any insights?

@alblue
Copy link
Contributor

alblue commented Aug 29, 2017

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:

apple/swift-corelibs-foundation@a7003d5

@dcci
Copy link
Mannequin Author

dcci mannequin commented Aug 29, 2017

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.

@dcci
Copy link
Mannequin Author

dcci mannequin commented Aug 29, 2017

FWIW, this one is using a system clang (`3.8.0`) for linking, maybe it needs something else?

@dcci
Copy link
Mannequin Author

dcci mannequin commented Aug 30, 2017

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 🙂

@dcci
Copy link
Mannequin Author

dcci mannequin commented Aug 30, 2017

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.

@dcci
Copy link
Mannequin Author

dcci mannequin commented Sep 10, 2017

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).

@dcci
Copy link
Mannequin Author

dcci mannequin commented Sep 10, 2017

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).

@alblue
Copy link
Contributor

alblue commented Sep 11, 2017

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.

@dcci
Copy link
Mannequin Author

dcci mannequin commented Sep 11, 2017

FWIW, I tried on Ubuntu and if you don't install `libblocks-runtime-dev` separately, you end up with the same problem (missing header).
So it seems the detection of Block.h should be fixed (presumably, copying what Mac OS does).

@compnerd
Copy link
Collaborator

We build and package blocks runtime as part of dispatch now.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. Fedora Platform: Fedora
Projects
None yet
Development

No branches or pull requests

3 participants