c'tor和d'tor从抽象基础到其他抽象类的继承到具体

Question

Main Question

I am trying to build a clang plugin as per the instructions here , but I am encountering linker errors when I try to build.

These are the errors:

/tmp/Test-1ea47e.o: In function `ASTFrontendAction':
/usr/lib/llvm-3.4/include/clang/Frontend/FrontendAction.h:216: undefined reference to `clang::FrontendAction::FrontendAction()'

/tmp/Test-1ea47e.o: In function `~TestPlugin':
/home/path/to/plugin/Test.cpp:12: undefined reference to `clang::FrontendAction::~FrontendAction()'

/tmp/Test-1ea47e.o:(.data.rel.ro+0x20): undefined reference to `clang::FrontendAction::~FrontendAction()'

/tmp/Test-1ea47e.o:(.data.rel.ro+0x50): undefined reference to `typeinfo for clang::PluginASTAction'

My class is TestPlugin (code is below), and it extends from three abstract library classes in the following chain: FrontendAction > ASTFrontendAction > PluginASTAction > TestPlugin . I would have expected that since the library classes are abstract, their constructors and destructors would never be needed, but I am fairly new to C++, so kindly correct me, if I'm wrong. What might be causing these linker errors?

Supplementary Info

For background: the instructions I'm following are meant for clang 3.7, but I am on the standard Ubuntu distribution of clang 3.4, so that could be part of the problem. The unmodified tutorial code wouldn't even compile, so I had to make a number of changes (mostly deletions) to get this far, but I am still getting the aforementioned errors during linking.

Here is my entire plugin file (some whitespace condensed for brevity)

Test.cpp :

#include "clang/AST/AST.h"
#include "clang/AST/ASTContext.h"
#include "clang/AST/ASTConsumer.h"
#include "clang/Frontend/FrontendPluginRegistry.h"
#include "clang/Frontend/CompilerInstance.h"
#include "clang/Frontend/FrontendAction.h"
#include "clang/Tooling/Tooling.h"
#include "llvm/Support/raw_ostream.h"
using namespace clang;

namespace {
    class TestPlugin: public PluginASTAction {
        private:
            void anchor(){}

        protected:
            ASTConsumer* CreateASTConsumer(CompilerInstance &CI, llvm::StringRef){ return NULL; }
            void ExecuteAction(){ return; }
            bool shouldEraseOutputFiles(){ return false; }

        public:
            bool ParseArgs(const CompilerInstance &CI, const std::vector<std::string>& args){ return true; }
    };
}

static FrontendPluginRegistry::Add<TestPlugin>
    X("test-stuff", "Does some test stuff");

int main(){ return 0; }

And here are the relevant parts (I think) of the library code from which mine inherits

FrontendAction.h :

//////// snip ////////
namespace clang {

    class FrontendAction {
    //////// snip ////////
        public:
            FrontendAction();
            virtual ~FrontendAction();
            virtual bool usesPreprocessorOnly() const = 0;
            //////// snip ////////
    }; // class FrontendAction


    class ASTFrontendAction : public FrontendAction {
        protected:
            virtual void ExecuteAction();

        public:
            virtual bool usesPreprocessorOnly() const { return false; }
    }; // class ASTFrontendAction


    class PluginASTAction : public ASTFrontendAction {
            virtual void anchor();

        protected:
            virtual ASTConsumer *CreateASTConsumer(CompilerInstance &CI, StringRef InFile) = 0;

        public:
            virtual bool ParseArgs(const CompilerInstance &CI, const std::vector<std::string> &arg) = 0;
    }; // class PluginASTAction

    //////// snip ////////
} // namespace clang

I'm Happy to provide any other information that might be useful.

Update

Here is the output that nm gives for the whereabouts of the c'tor and d'tor:

/usr/lib/llvm-3.4/lib$ nm -AC *.a | grep 'FrontendAction::~\?FrontendAction'
...
libclangFrontend.a:FrontendAction.o:00000960 T clang::FrontendAction::FrontendAction()
libclangFrontend.a:FrontendAction.o:000004a0 T clang::FrontendAction::~FrontendAction()
...

They show up in libclangFrontend.a with status 'T', which I understand to mean that the implementation of the method is there. They also show up in several other libraries with status 'U' (undefined). libclangFrontend.a also claims to hold the missing typeinfo for clang::PluginASTAction .

However, I was already including that library, and even after positioning it before the other libclangXYZ libs I still get the same error. Here is my current linker invocation (generated by make , linebreaks added for readability):

"/usr/bin/ld"
    -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_i386
    -dynamic-linker /lib/ld-linux.so.2

    -o Test

    /usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crt1.o
    /usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crti.o
    /usr/bin/../lib/gcc/i686-linux-gnu/4.8/crtbegin.o

    -L/usr/lib/llvm-3.4/lib/
    -L/usr/bin/../lib/gcc/i686-linux-gnu/4.8
    -L/usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu
    -L/lib/i386-linux-gnu
    -L/usr/lib/i386-linux-gnu
    -L/usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../..
    -L/lib
    -L/usr/lib

    -lpthread -lffi -ltinfo -ldl -lm

    -lclangFrontend
    -lclang
    -lclangBasic
    -lclangAST
    -lclangFrontendTool
    -lclangRewriteFrontend
    -lclangStaticAnalyzerFrontend
    -lclangCodeGen
    -lclangTooling
    -lclangARCMigrate
    -lclangTidy

    /tmp/Test-fd7749.o

    -lc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc

    /usr/bin/../lib/gcc/i686-linux-gnu/4.8/crtend.o
    /usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o

Update: Solved!

It turns out that I was missing a ton of LLVM libraries (eg libLLVMSupport.a ) and some clang ones too from the linker invocation. I think I also needed to explicitly add libstdc++.so .

Here is the final working call to the linker, generated by make (note: I'm not sure this is a minimal set, but at least it links...):

"/usr/bin/ld"
    -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_i386
    -dynamic-linker /lib/ld-linux.so.2

    -o Test

    /usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crt1.o
    /usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crti.o
    /usr/bin/../lib/gcc/i686-linux-gnu/4.8/crtbegin.o

    -L/usr/lib/llvm-3.4/lib
    -L/usr/bin/../lib/gcc/i686-linux-gnu/4.8
    -L/usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu
    -L/lib/i386-linux-gnu
    -L/usr/lib/i386-linux-gnu
    -L/usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../..
    -L/lib
    -L/usr/lib

    /tmp/Test-6c811b.o

    /usr/lib/gcc/i686-linux-gnu/4.8/libstdc++.so

    -lpthread -lffi -ltinfo -ldl -lm -lc++

    -lclangFrontend
    -lclangSerialization
    -lclangDriver
    -lclangTooling
    -lclangParse
    -lclangSema
    -lclangStaticAnalyzerFrontend
    -lclangStaticAnalyzerCheckers
    -lclangStaticAnalyzerCore
    -lclangAnalysis
    -lclangRewriteFrontend
    -lclangEdit
    -lclangAST
    -lclangLex
    -lclangBasic

    -lLLVMTransformUtils
    -lLLVMCore
    -lLLVMSupport
    -lLLVMOption
    -lLLVMMCParser
    -lLLVMMC
    -lLLVMBitReader

    -lc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc

    /usr/bin/../lib/gcc/i686-linux-gnu/4.8/crtend.o
    /usr/bin/../lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o

Answer 1

This looks like you are not linking with whatever implements clang::FrontendAction::~FrontendAction() . Try looking at this Makefile: http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-check/Makefile?view=markup

In this article , it put this in your cmake file:

set(LLVM_USED_LIBS clangTooling clangBasic clangAST)

Answer 2

I would have expected that since the library classes are abstract, their constructors and destructors would never be needed.

All classes need constructors and destructors if they are instantiated. That includes abstract classes - even though they can't be directly instantiated, they can be instantiated as part of the concrete derived class, and the constructor and destructor are needed for that.

What might be causing these linker errors?

You declare the destructor, but don't define it. If it doesn't need to do anything (as is usually the case in an abstract class), you can just define it with an empty body

virtual ~FrontendAction() {}

or as defaulted

virtual ~FrontendAction() = default;

in the class definition.