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

Tue Jan 27 14:34:53 PST 2015

On Tue, Jan 20, 2015 at 4:32 PM, Nico Weber <thakis at chromium.org> wrote:

> On Tue, Jan 20, 2015 at 11:07 AM, Reid Kleckner <rnk at google.com> wrote:
>
>> I think Nico tweaked the dead strip settings last?
>>
>
> I tested things in a static library build. Since you say something about
> libLLVMSupport.dylib, you're probably doing a shared build. From how I
> remember things looking, I don't think shared builds supported plugins ever
> in the make build – it's probably you'll have to tweak the build
> description to get this configuration to work. (Chromium only uses compiler
> plugins in static builds too.)
>

How should I get a non-shared build?  That may be the source of this
problem...

> Nico
>
>
>>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>

-- 
Ehsan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150127/00b00d30/attachment.html>