C++ polymorphism not working with ESP-IDF

Question

I have an abstract class

namespace AComp
{
   class A 
    { 
    public:
      virtual void func() = 0;
      virtual ~A();
    };
    A::~A() { }
}

I also have an abstract sub-class which does not provide implementation for the pure virtual member

namespace BComp
{
    class B : public AComp::A
    {
    public:
      virtual void func() override = 0;
      virtual ~B() override;
    };
    B::~B() { }
}

Then I have a subclass providing implementation

namespace CComp
{
    class C : public BComp::B
    {
    public:
      virtual void func() override;
    };

    void C::func() { }
}

Finally, in my class which uses class C I have

AComp::A * instanceOfA = new CComp::C();

The linker throws the following error

undefined reference to 'vtable for B'

I thought it was something really stupid, but I cannot figure out what the issue is.

This code is to run on an ESP-32 microprocessor and it's all written using VisualCode and the ESP-IDF framework, where: A is in component Acomp, B is in component Bcomp, C is in component Ccomp and the calling code is in the main App

I've run the code through several online compilers and there appears to be no issues, however I do get the linker error

Compiler info

-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- The ASM compiler identification is GNU
-- Found assembler: A:/espressif/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: A:/espressif/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: A:/espressif/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building ESP-IDF components for target esp32

Answer 1

I'm providing the answer to my own question so that anyone coming across the same issue won't have to read through the comments on the OP to find the answer.

As it turned out, it was indeed a case of user error, but it was not as "dumb" as I originally thought -but it was still something that a full-time C++ programmer would have most likely not encountered.

My caveat is that I have not used C++ "in anger" for a number of years and rather I have been working with higher level languages -mostly C#, with the occasional dip into Java

I have to credit @BenVoigt for his dilligence and persistence in finding the actual issue

The proximate cause is "the compiler didn't generate the vtable because it thought someone else (compiler running on another file) was going to do it". There's half a dozen things influencing that behavior, so it's hard to label any one of them as "the root cause". Do double-check that every single other virtual function in B has a definition and the definition is getting linked in. The linked explanation (stackoverflow.com/a/26928723/103167) suggests the problem is either (a) the first (in source code order) declared virtual functions or (b) a virtual function inherited from A that isn't pure in B.

I also have to credit both @n.m.couldbeanAI and @Ted Lyngmo for insisting upon a minimal reproducible example

I placed the code as is from the OP in a new project, and unsurprisingly everything was fine, i.e. the code compiled and linked without error. This lead me to go back to the actual code in the project I was working on which had given me cause to pose the question here. There was clearly something else going on within that codebase that I had not represented in the OP.

As it turned out, there were some extra (and pertinent) features in my real codebase. The additions were to both BComp::B and CComp::C. The true representation therefore became

namespace BComp
{
    class B : public AComp::A
    {
    protected:
     virtual void func1();
     virtual void func2();
    public:
      virtual void func() override = 0;
      virtual ~B() override;
    };
    B::~B() { }
}

namespace CComp
{
    class C : public BComp::B
    {
    public:
      virtual void func() override;
    };

    void C::func() { }
    void C::func1() { }
    void C::func2() { }
}

As you can see, BComp also declares some other non-pure virtual members, which are implememnted in the sub-class CComp::C. Now, to any C#, VB.Net, Java, etc. users, this would appear natural, however, as @BenVoigt pointed out:

If you declare a virtual member function, you have to either provide a definition in the same class or make it pure and provide a definition in a sub-class. Definition in sub-class is not good enough by itself.

And so, the solution to the problem -which took a whole day of investigation by an experienced software engineer (that would be me!)- was in fact to adhere to the rules of C++ programming, and had NOTHING to do with the target (ESP32), the compiler, or the linker.

And here is the solution: make the virtual members of BComp::B pure:

namespace BComp
{
    class B : public AComp::A
    {
    protected:
     virtual void func1() = 0;
     virtual void func2() = 0;
    public:
      virtual void func() override = 0;
      virtual ~B() override;
    };
    B::~B() { }
}

Thanks again to all who contributed their time and effort. I will leave you with this summary (once again from @BenVoigt)

Normally the linker would have given you unresolved external errors for the virtual functions that didn't have definitions in B. But the error message would have been "unresolved B::bar() referenced in vtable of B". Since you were also missing the vtable, none of those more meaningful errors were seen. Because the toolchain was dumb and generated an error for something the programmer is never supposed to see, instead of a meaningful message about the real problem, it took you a whole day to solve. That makes for a good StackOverflow question. So now that you know the important parts (A isn't, func() isn't, the virtual function declared in B and implemented in C is).