class A { A(); virtual void B(); }; A::A() {} /* Whoops, I forgot to define A::B() */ $ g++ -Wall a.cc /usr/lib/../lib/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' /tmp/ccaVlePI.o: In function `A::A()': a.cc:(.text+0xf): undefined reference to `vtable for A' collect2: ld returned 1 exit status bug submitter writes: "To be clear: the problem is that the error message only mentions the constructor, and the vtable. It doesn't mention the method A::B(), which is actually the problem. On a less-minimal example it could take much longer to work out what the real problem is."
I don't know if there is anything there could be done here since the linker is what is producing the error.
In fact it depends on the key function being declared which depends on the ABI really (ARM EABI has a slightly different key function than the rest of the abis).
The linker error alone doesn't make the root cause obvious, but it's a fairly well known and well documented problem: http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.10
Is it impossible to detect this in the compiler? Can't we put the vtable somewhere else (or break it in pieces) such triggering the error in the compiler? Otherwise, we should just close this as WONTFIX.
As suggested, there's no bug in the compiler here, and the error message comes from the linker. The linker doesn't know what the key function is, so I doubt it could issue a more accurate diagnostic. In fact, the key function is just a trigger to the compiler to cause it to emit the meta-data for the class exactly once -- and because there the class could be used in multiple compilation units it can never know which one should contain the meta data as any of them could have done. As far as the linker is concerned, there really is no class for A; it's the same as if there was no definition for a global extern variable.
*** Bug 44841 has been marked as a duplicate of this bug. ***
I'm working on a patch for this at http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01116.html. It works by emitting a fake use of the key method any time a translation unit depends on an imported vtable or typeinfo.
Reopening ....
Pending for 4.7
Mark asked for a different implementation in http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00367.html, and I may not get a chance to do what he asked for 4.7. Someone else is welcome to pick this up if they have time.
The example in this bug is not as severe and frequent as the one in bug 44841. Users are more likely to encounter this issue when adding a new API to existing interface or type erasure. Calling this a "well-known issue" is irresponsible. The issue significantly increases the bar to learners to consume and accept new paradigms in the language. The issue has not been fixed for ten years. It is a shame rather than some arcane knowledge that worth to be proud of. MSVC has no such issue. The error message reads as "undefined reference to Class::that_virtual_function." Some possible fixes: 1. Adjust the error message to say, "The first non-inline, non-pure function may not have a definition in <Class>." 2. Add extra information to name the key function, and pass it to the linker, generate an error message to match MSVC's quality.
(In reply to Zhihao Yuan from comment #11) > 1. Adjust the error message to say, "The first non-inline, non-pure function > may not have a definition in <Class>." That error comes from the linker. The linker is not part of GCC, so this is the wrong place to ask for linker changes. > 2. Add extra information to name the key function, and pass it to the > linker, generate an error message to match MSVC's quality. That's what comment 7 suggested. Comment 10 links to the response to that.
(In reply to Jonathan Wakely from comment #3) > The linker error alone doesn't make the root cause obvious, but it's a > fairly well known and well documented problem: > http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.10 A better link is now: https://gcc.gnu.org/wiki/VerboseDiagnostics#undefined_reference_to_vtable_for_X
*** Bug 96283 has been marked as a duplicate of this bug. ***
*** Bug 104918 has been marked as a duplicate of this bug. ***
Some comments following my recent dupe... (In reply to Andrew Pinski from comment #1) > I don't know if there is anything there could be done here since the linker > is what is producing the error. The compiler could store information in the compiled object listing the virtual members for which no implementation was found, due to which reason the vtable was not defined already. In this specific example, storing the name of "A::B()" somewhere. If that information is available, we could then petition linker authors to use it and print the missing virtual members in the error message. (In reply to Richard Earnshaw from comment #5) > As suggested, there's no bug in the compiler here Not passing sufficient information to the linker is a "bug", or at least - a missing feature. (In reply to Zhihao Yuan from comment #11) > 2. Add extra information to name the key function, and pass it to the linker, generate an error message to match MSVC's quality. I'm not quite sure what a key function is, but it sounds like my suggestion is similar to this one. So, I support your suggestion (2.) > Calling this a "well-known issue" is irresponsible. The issue significantly > increases the bar to learners to consume and accept new paradigms in the > language. Not just learners. If you have a large class with many methods, whose implementation is spread across many files, it can take quite a bit of time to figure out which method implementation is missing.
(In reply to Eyal Rozenberg from comment #16) > I'm not quite sure what a key function is, Then read the link I gave you in PR 104918 comment 1. > Not just learners. If you have a large class with many methods, whose > implementation is spread across many files, it can take quite a bit of time > to figure out which method implementation is missing. The first one. They key function is the first non-inline, non-pure virtual function. Read the wiki page. I didn't write that page and suggest you read it just for fun. The linker could easily say that, with no changes from GCC. That belongs in the binutils bugzilla though.
(In reply to Eyal Rozenberg from comment #16) > The compiler could store information in the compiled object listing the > virtual members for which no implementation was found, due to which reason > the vtable was not defined already. In this specific example, storing the > name of "A::B()" somewhere. In every file that includes the header defining A? Consider the case where you include the header in ten files, and define the virtual functions in one of them. Nine out of ten files do not contain a definitions of the virtual functions, so they would each contain the same info naming every virtual function in the class. Then do that for every polymorphic class in every object file. This is a lot more info being written out, and most of it will never be used. You have nine files saying "this function is missing" and one not saying it. What exactly does the linker do with that information? Why would that be better than comment 7 here?
(In reply to Jonathan Wakely from comment #17) Ok, have read the wiki page. > The linker could easily say that, with no changes from GCC. Is the signature, or name, of the "key function" present in compiled object files which have seen the class definition? If the answer is yes, we could just go ahead and file a bug against binutils...
No, but "the first non-pure, non-inline virtual function in the class" is easy for the user to find.
(In reply to Jonathan Wakely from comment #20) > No, but "the first non-pure, non-inline virtual function in the class" is > easy for the user to find. Well, yes, granted, that would be a huge improvement. But then, is binutils allowed to make that assumption about the ABI? ... actually, never mind. Even if it isn't, they could still write something like "The probable cause is a lack of definition of the first virtual method in the class which isn't inline nor pure-virtual".
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-vtable The ABI specifies it
Unassigned so that someone else can take it they wish to.
For completeness, this is what LLD says: ld.lld: error: undefined symbol: vtable for A >>> referenced by example.cpp:7 >>> /tmp/example-5d8b98.o:(A::A()) >>> the vtable symbol may be undefined because the class is missing its key function (see https://lld.llvm.org/missingkeyfunction) which seems better.
Yes, and it 1) refers to the key function and 2) is done by the linker not the compiler. Which is what I've been suggesting. If binutils wants to do this and wants to provide a URL, we'll need a more permanent home for the info at https://gcc.gnu.org/wiki/VerboseDiagnostics#undefined_reference_to_vtable_for_X