You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
swift version: DEVELOPMENT-SNAPSHOT-2018-11-01-a
swift pm version: DEVELOPMENT-SNAPSHOT-2018-11-01-a
Xcode: Version 10.1 (10B61)
Xcode Toolchain: Swift Development Snapshot 2018-11-01 (a)
Additional Detail from JIRA
Votes
0
Component/s
Package Manager
Labels
Bug, Screened
Assignee
None
Priority
Medium
md5: 960dea92de539801c320fe8e5d36f09f
Issue Description:
After switching SwiftPM dependency version to `.branch("master")`, sourcekit-lsp now having llbuild as dependency which contains a target named `llvmSupport`
After executing
swift package generate-xcodeproj --xcconfig-overrides overrides.xcconfig
Open the generated `SourceKitLSP.xcodeproj` trying to build it. First I found a error related to SR-8018 .
Due to generated xcodeproj do not add `SWIFT_PACKAGE` macro to `GCC_PREPROCESSOR_DEFINITIONS`, the workaround in COFF.h
#ifdefSWIFT_PACKAGE#undef DEBUG
#endif
will not be triggered.
This issue can be fixed by manually adding `SWIFT_PACKAGE=1` to `GCC_PREPROCESSOR_DEFINITIONS` in project build settings.
Then I found build failed with error message:
Ld /Users/ainopara/Library/Developer/Xcode/DerivedData/SourceKitLSP-fnjsratimrzzuhcgogbpmfzxmawj/Build/Products/Debug/llvmSupport.framework/Versions/A/llvmSupport normal x86_64 (in target: llvmSupport)
cd /Users/ainopara/Documents/Projects/sourcekit-lsp
export MACOSX_DEPLOYMENT_TARGET=10.10
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -L/Users/ainopara/Library/Developer/Xcode/DerivedData/SourceKitLSP-fnjsratimrzzuhcgogbpmfzxmawj/Build/Products/Debug -F/Users/ainopara/Library/Developer/Xcode/DerivedData/SourceKitLSP-fnjsratimrzzuhcgogbpmfzxmawj/Build/Products/Debug -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -filelist /Users/ainopara/Library/Developer/Xcode/DerivedData/SourceKitLSP-fnjsratimrzzuhcgogbpmfzxmawj/Build/Intermediates.noindex/SourceKitLSP.build/Debug/llvmSupport.build/Objects-normal/x86_64/llvmSupport.LinkFileList -install_name @rpath/llvmSupport.framework/Versions/A/llvmSupport -Xlinker -rpath -Xlinker /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2018-11-01-a.xctoolchain/usr/lib/swift/macosx -mmacosx-version-min=10.10 -Xlinker -object_path_lto -Xlinker /Users/ainopara/Library/Developer/Xcode/DerivedData/SourceKitLSP-fnjsratimrzzuhcgogbpmfzxmawj/Build/Intermediates.noindex/SourceKitLSP.build/Debug/llvmSupport.build/Objects-normal/x86_64/llvmSupport_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -framework CoreServices -Xlinker -dependency_info -Xlinker /Users/ainopara/Library/Developer/Xcode/DerivedData/SourceKitLSP-fnjsratimrzzuhcgogbpmfzxmawj/Build/Intermediates.noindex/SourceKitLSP.build/Debug/llvmSupport.build/Objects-normal/x86_64/llvmSupport_dependency_info.dat -o /Users/ainopara/Library/Developer/Xcode/DerivedData/SourceKitLSP-fnjsratimrzzuhcgogbpmfzxmawj/Build/Products/Debug/llvmSupport.framework/Versions/A/llvmSupport
Undefined symbols for architecture x86_64:
"_AnnotateHappensAfter", referenced from:
llvm::ManagedStatic<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::operator->() in Debug.o
llvm::ManagedStatic<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::operator*() in Debug.o
llvm::ManagedStatic<llvm::sys::SmartMutex<false> >::operator*() in ErrorHandling.o
llvm::ManagedStatic<llvm::sys::SmartMutex<false> >::operator*() in Process.o
llvm::ManagedStatic<llvm::sys::SmartMutex<true> >::operator*() in Signals.o
llvm::ManagedStatic<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::operator*() in Signals.o
llvm::ManagedStatic<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::operator->() in Signals.o
...
"_AnnotateHappensBefore", referenced from:
llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) const in ManagedStatic.o
"_AnnotateIgnoreWritesBegin", referenced from:
llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) const in ManagedStatic.o
"_AnnotateIgnoreWritesEnd", referenced from:
llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) const in ManagedStatic.o
"llvm::raw_ostream::anchor()", referenced from:
vtable for llvm::circular_raw_ostream in circular_raw_ostream.o
"llvm::raw_ostream::operator<<(llvm::formatv_object_base const&)", referenced from:
llvm::json::ParseError::log(llvm::raw_ostream&) const in JSON.o
"llvm::isLegalUTF8String(unsigned char const**, unsigned char const*)", referenced from:
llvm::json::isUTF8(llvm::StringRef, unsigned long*) in JSON.o
"llvm::ConvertUTF32toUTF8(unsigned int const**, unsigned int const*, unsigned char**, unsigned char*, llvm::ConversionFlags)", referenced from:
toUTF8(unsigned int, llvm::MutableArrayRef<unsigned char>) in DJB.o
llvm::json::fixUTF8(llvm::StringRef) in JSON.o
"llvm::ConvertUTF8toUTF32(unsigned char const**, unsigned char const*, unsigned int**, unsigned int*, llvm::ConversionFlags)", referenced from:
chopOneUTF32(llvm::StringRef&) in DJB.o
llvm::json::fixUTF8(llvm::StringRef) in JSON.o
"llvm::SmallPtrSetImplBase::insert_imp_big(void const*)", referenced from:
llvm::SmallPtrSetImplBase::insert_imp(void const*) in CommandLine.o
"llvm::consumeUnsignedInteger(llvm::StringRef&, unsigned int, unsigned long long&)", referenced from:
std::__1::enable_if<!(std::numeric_limits<unsigned long>::is_signed), bool>::type llvm::StringRef::consumeInteger<unsigned long>(unsigned int, unsigned long&) in FormatVariadic.o
std::__1::enable_if<!(std::numeric_limits<unsigned long>::is_signed), bool>::type llvm::StringRef::consumeInteger<unsigned long>(unsigned int, unsigned long&) in JSON.o
"llvm::report_bad_alloc_error(char const*, bool)", referenced from:
llvm::safe_malloc(unsigned long) in CommandLine.o
llvm::safe_calloc(unsigned long, unsigned long) in FoldingSet.o
llvm::safe_malloc(unsigned long) in FoldingSet.o
llvm::safe_malloc(unsigned long) in StringSaver.o
llvm::safe_malloc(unsigned long) in Timer.o
llvm::SmallVectorTemplateBase<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, false>::grow(unsigned long) in YAMLTraits.o
llvm::safe_malloc(unsigned long) in YAMLTraits.o
...
"llvm::sys::path::is_relative(llvm::Twine const&, llvm::sys::path::Style)", referenced from:
ExpandResponseFile(llvm::StringRef, llvm::StringSaver&, void (*)(llvm::StringRef, llvm::StringSaver&, llvm::SmallVectorImpl<char const*>&, bool), llvm::SmallVectorImpl<char const*>&, bool, bool) in CommandLine.o
"llvm::sys::path::parent_path(llvm::StringRef, llvm::sys::path::Style)", referenced from:
ExpandResponseFile(llvm::StringRef, llvm::StringSaver&, void (*)(llvm::StringRef, llvm::StringSaver&, llvm::SmallVectorImpl<char const*>&, bool), llvm::SmallVectorImpl<char const*>&, bool, bool) in CommandLine.o
"llvm::sys::path::filename(llvm::StringRef, llvm::sys::path::Style)", referenced from:
(anonymous namespace)::CommandLineParser::ParseCommandLineOptions(int, char const* const*, llvm::StringRef, llvm::raw_ostream*) in CommandLine.o
"llvm::sys::Process::GetTimeUsage(std::__1::chrono::time_point<std::__1::chrono::system_clock, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> > >&, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> >&, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> >&)", referenced from:
llvm::TimeRecord::getCurrentTime(bool) in Timer.o
"llvm::yaml::Stream::Stream(llvm::MemoryBufferRef, llvm::SourceMgr&, bool, std::__1::error_code*)", referenced from:
llvm::yaml::Input::Input(llvm::MemoryBufferRef, void*, void (*)(llvm::SMDiagnostic const&, void*), void*) in YAMLTraits.o
"llvm::yaml::Stream::Stream(llvm::StringRef, llvm::SourceMgr&, bool, std::__1::error_code*)", referenced from:
llvm::yaml::Input::Input(llvm::StringRef, void*, void (*)(llvm::SMDiagnostic const&, void*), void*) in YAMLTraits.o
"llvm::yaml::escape(llvm::StringRef, bool)", referenced from:
llvm::yaml::Output::scalarString(llvm::StringRef&, llvm::yaml::QuotingType) in YAMLTraits.o
"llvm::StringRef::split(llvm::SmallVectorImpl<llvm::StringRef>&, char, int, bool) const", referenced from:
llvm::Triple::Triple(llvm::Twine const&) in Triple.o
llvm::Triple::normalize(llvm::StringRef) in Triple.o
"vtable for llvm::raw_pwrite_stream", referenced from:
llvm::raw_pwrite_stream::raw_pwrite_stream(bool) in MD5.o
llvm::raw_pwrite_stream::raw_pwrite_stream(bool) in NativeFormatting.o
llvm::raw_pwrite_stream::raw_pwrite_stream(bool) in PrettyStackTrace.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"_del_curterm", referenced from:
terminalHasColors(int) in Process.o
"_set_curterm", referenced from:
terminalHasColors(int) in Process.o
"_setupterm", referenced from:
terminalHasColors(int) in Process.o
"_tigetnum", referenced from:
terminalHasColors(int) in Process.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
At the same time, building sourcekit-lsp with
swift build
will succeed.
The difference is that `swift build` will not generate a LLVMSupport.framework, in fact all the .o file generated with `LLVMSupport` target will only be linked when sourcekit-lsp generated and in this case swiftc is used to generate the binary rather than clang++.
Is there anything I can do to workaround this issue too?
It seems the fact that both `IndexStoreDB` and `llbuild` has the target `LLVMSupport` may be the source of this issue. The target in `llbuild` named `llvmSupport` seems not identical to `LLVMSupport`, but the APFS on my mac is case insensitive file system. The issue can be reproduced by build swift-package-manager project alone with generated xcodeproj.
Finally I got sourcekit-lsp build with generated xcodeproj by applying following modifications:
Add `SWIFT_PACKAGE=1` to `GCC_PREPROCESSOR_DEFINITIONS` in build settings of project `SourceKitLSP`.
Rename LLVMSupport to LLVMSupport1 in `Package.swift` of IndexStoreDB.
// Support code that is generally useful to the C++ implementation..target(
name:"IndexStoreDB_Support",
dependencies:["LLVMSupport1"],
path:"lib/Support"),// Copy of a subset of llvm's ADT and Support libraries..target(
name:"LLVMSupport1",
dependencies:[],
path:"lib/LLVMSupport"),
The naming conflect actually is a source of this issue, though not the only source.
The text was updated successfully, but these errors were encountered:
SwiftPM should diagnose case-insensitive module name conflicts, since they blow up on case-insensitive file systems
Ideally we shouldn't have to add the linking flags for ncurses & sqlite3, but maybe the fix for this is to adopt target-specific build settings when they're available?
Environment
swift version: DEVELOPMENT-SNAPSHOT-2018-11-01-a
swift pm version: DEVELOPMENT-SNAPSHOT-2018-11-01-a
Xcode: Version 10.1 (10B61)
Xcode Toolchain: Swift Development Snapshot 2018-11-01 (a)
Additional Detail from JIRA
md5: 960dea92de539801c320fe8e5d36f09f
Issue Description:
After switching SwiftPM dependency version to `.branch("master")`, sourcekit-lsp now having llbuild as dependency which contains a target named `llvmSupport`
After executing
Open the generated `SourceKitLSP.xcodeproj` trying to build it. First I found a error related to SR-8018 .
Due to generated xcodeproj do not add `SWIFT_PACKAGE` macro to `GCC_PREPROCESSOR_DEFINITIONS`, the workaround in COFF.h
will not be triggered.
This issue can be fixed by manually adding `SWIFT_PACKAGE=1` to `GCC_PREPROCESSOR_DEFINITIONS` in project build settings.
Then I found build failed with error message:
At the same time, building sourcekit-lsp with
will succeed.
The difference is that `swift build` will not generate a LLVMSupport.framework, in fact all the .o file generated with `LLVMSupport` target will only be linked when sourcekit-lsp generated and in this case swiftc is used to generate the binary rather than clang++.
Related fragment in `.build/debug.yaml`:
Is there anything I can do to workaround this issue too?It seems the fact that both `IndexStoreDB` and `llbuild` has the target `LLVMSupport` may be the source of this issue. The target in `llbuild` named `llvmSupport` seems not identical to `LLVMSupport`, but the APFS on my mac is case insensitive file system.The issue can be reproduced by build swift-package-manager project alone with generated xcodeproj.Finally I got sourcekit-lsp build with generated xcodeproj by applying following modifications:
The naming conflect actually is a source of this issue, though not the only source.
The text was updated successfully, but these errors were encountered: