[cfe-dev] Linking a plugin against clang/LLVM libraries

[Reid Kleckner]

I think Nico tweaked the dead strip settings last?

On Wed, Dec 31, 2014 at 9:02 AM, Ehsan Akhgari <ehsan.akhgari at gmail.com>
wrote:

> Hi all,
>
> I'm trying to compile a clang plugin against a local ToT build of clang on
> OSX 10.10.  The link command fails like this:
>
> $ /Users/ehsan/src/llvm-objdir/bin/clang++ -Qunused-arguments
> -I/Users/ehsan/src/llvm/include -I/Users/ehsan/src/llvm-objdir/include
> -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
> -Wno-long-long -Wcovered-switch-default -std=c++11 -fcolor-diagnostics -O2
> -g -DNDEBUG  -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> -D__STDC_LIMIT_MACROS -fno-rtti -fno-exceptions -fno-omit-frame-pointer
> -fPIC -shared -o libclang-plugin.dylib  clang-plugin.o
> -L/Users/ehsan/src/llvm-objdir/lib -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names -lcurses -lpthread -lz -lm
> -L/Users/ehsan/src/llvm-objdir/lib -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names -lLLVMOption -lLLVMBitReader
> -lLLVMMCParser -lLLVMAsmParser -lLLVMAnalysis -lLLVMTarget -lLLVMMC
> -lLLVMCore -lLLVMSupport -lclangFrontend -lclangDriver -lclangSerialization
> -lclangParse -lclangSema -lclangAnalysis -lclangEdit -lclangAST -lclangLex
> -lclangBasic -lclangASTMatchers
> -Wl,-executable_path,/Users/ehsan/moz/src/obj-ff-clang-plugin.noindex/dist/bin
> -dynamiclib -install_name @executable_path/libclang-plugin.dylib
> -compatibility_version 1 -current_version 1 -single_module
> Undefined symbols for architecture x86_64:
>   "llvm::MemoryBuffer::getOpenFile(int, llvm::Twine const&, unsigned long
> long, bool, bool)", referenced from:
>       (anonymous namespace)::RealFile::getBuffer(llvm::Twine const&, long
> long, bool, bool) in libclangBasic.a(VirtualFileSystem.cpp.o)
>   "llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, llvm::Twine
> const&)", referenced from:
>       clang::Preprocessor::EnterMainSourceFile() in
> libclangLex.a(Preprocessor.cpp.o)
>       clang::createChainedIncludesSource(clang::CompilerInstance&,
> llvm::IntrusiveRefCntPtr<clang::ExternalSemaSource>&) in
> libclangFrontend.a(ChainedIncludesSource.cpp.o)
>
> clang::ASTUnit::getMainBufferWithPrecompiledPreamble(clang::CompilerInvocation
> const&, bool, unsigned int) in libclangFrontend.a(ASTUnit.cpp.o)
>
> clang::GenerateModuleAction::BeginSourceFileAction(clang::CompilerInstance&,
> llvm::StringRef) in libclangFrontend.a(FrontendActions.cpp.o)
>   "llvm::MemoryBuffer::getNewUninitMemBuffer(unsigned long, llvm::Twine
> const&)", referenced from:
>       clang::Preprocessor::SetCodeCompletionPoint(clang::FileEntry const*,
> unsigned int, unsigned int) in libclangLex.a(Preprocessor.cpp.o)
>   "llvm::MemoryBuffer::getFile(llvm::Twine const&, long long, bool,
> bool)", referenced from:
>       clang::CompilerInvocation::getModuleHash() const in
> libclangFrontend.a(CompilerInvocation.cpp.o)
>       clang::createVFSFromCompilerInvocation(clang::CompilerInvocation
> const&, clang::DiagnosticsEngine&) in
> libclangFrontend.a(CompilerInvocation.cpp.o)
>       clang::GlobalModuleIndex::readIndex(llvm::StringRef) in
> libclangSerialization.a(GlobalModuleIndex.cpp.o)
>       clang::PTHManager::Create(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > const&,
> clang::DiagnosticsEngine&) in libclangLex.a(PTHLexer.cpp.o)
>       clang::driver::toolchains::Linux::Linux(clang::driver::Driver
> const&, llvm::Triple const&, llvm::opt::ArgList const&) in
> libclangDriver.a(ToolChains.cpp.o)
>   "llvm::sys::findProgramByName(llvm::StringRef,
> llvm::ArrayRef<llvm::StringRef>)", referenced from:
>       clang::driver::Driver::GetProgramPath(char const*,
> clang::driver::ToolChain const&) const in libclangDriver.a(Driver.cpp.o)
>   "llvm::scalbn(llvm::APFloat, int)", referenced from:
>       (anonymous
> namespace)::ComplexExprEvaluator::VisitBinaryOperator(clang::BinaryOperator
> const*) in libclangAST.a(ExprConstant.cpp.o)
>   "llvm::APInt::sshl_ov(llvm::APInt const&, bool&) const", referenced from:
>       EvaluateDirectiveSubExpr((anonymous namespace)::PPValue&, unsigned
> int, clang::Token&, bool, clang::Preprocessor&) in
> libclangLex.a(PPExpressions.cpp.o)
>   "llvm::APInt::ushl_ov(llvm::APInt const&, bool&) const", referenced from:
>       EvaluateDirectiveSubExpr((anonymous namespace)::PPValue&, unsigned
> int, clang::Token&, bool, clang::Preprocessor&) in
> libclangLex.a(PPExpressions.cpp.o)
> ld: symbol(s) not found for architecture x86_64
> clang-3.5: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> The missing symbols are all in libLLVMSupport.a, but libLLVMSupport.dylib
> (which is the library that ld tries to link against) misses all of these
> symbols because they are not referenced by anything and were eliminated
> during linking.
>
> tools/driver/CMakeLists.txt in the clang repository sets
> LLVM_NO_DEAD_STRIP to 1 if CLANG_PLUGIN_SUPPORT is turned on, which it is
> in my build, but it seems like that setting does not affect libLLVMSupport,
> so we end up passing -dead_strip to the linker.  I'm not sure if this is
> the intended behavior, or a bug.
>
> Do I understand the setup as intended correctly?  Can someone please
> suggest a way to bypass this issue?
>
> Thanks!
> --
> Ehsan
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150120/fec41094/attachment.html>