undefined reference to `vtable for

SPlatten

This post is deleted!

JonB

@SPlatten
Dunno at this point, a bit difficult to spot with all that's going on. For me I would do the usual: comment "everything" out, preferably including the namespaces, till you get rid of that message. Then add back in....

J.Hilk

@SPlatten your class compiles perfectly fine for me, at least as long as I add the implementation of m_nextUDN, where exactly do you do that ?

I know you said/showed, you do it, but where exactly?

SPlatten

This post is deleted!

JoeCFD

Often make clean is not enough especially when cmake is used. Remove the whole build dir and recreate it.

JonB

@SPlatten
Yeah, but is that "global scope", i.e. not inside anything else?

@J-Hilk
The trouble is, without m_nextUDN defined properly, I do not get

undefined reference to vtable for asv::scm::helm::staledata_t'

message, I get complaint about m_nextUDN not being defined....

mchinand

Do the capital C/H extensions force compiling this with the c compiler instead of c++?

J.Hilk

@JonB yes, the error message probably changed after @SPlatten added the missing function body that the Q_PROPERTY macro referred to.

@SPlatten are you sure config.c is party of your project ? :D so the linker can find it

JonB

@SPlatten
I'm with @JoeCFD on one thing: if you get "incomprehensible"/"impossible" error messages, especially about vtables, with Qt you (may) need to do a "change underpants"-type clean rebuild. Preferable buy a new machine ;-) But if not delete the whole build output directory and try again.....

SPlatten

This post is deleted!

JonB

@SPlatten

@J-Hilk said in undefined reference to `vtable for:

@SPlatten are you sure config.c is party of your project ? :D so the linker can find it

?? Look at actual linker statement being executed?

Hmm, originally you showed

.build/config.o: In function asv::scm::helm::staledata_t::staledata_t()':

immediately above the undefined reference to vtable message. Is that still present? Because that does imply the linker is trying to pull in config.o, which would imply it does appear on the linker command line.... Is that indeed the right .build/config.o path for the config.o you keep rebuilding?

J.Hilk

@SPlatten

soooo, since you'e not using m_nextUDN anywhere else and its private.... have you considered simply using:

static uint16_t nextUDN() {
        static uint16_t m_nextUDN = 0;
        return ++(m_nextUDN);
    }

?

SPlatten

This post is deleted!

JoeCFD

@SPlatten not config.cpp or config.cc? it is not c code, right?

JonB

@JoeCFD
It it were compiled as C code, it wouldn't begin to compile :) So I think we can assume whatever his file extension it's being compiled as C++!

JoeCFD

@JonB it is wrong and should be changed since gcc(not g++) will be applied for it.

JonB

@JoeCFD
I'm guessing he has been using this for a while, seems strange this one and only error would show up now.

@SPlatten
I don't know whether this matters with gcc/g++. Do you want to show us the complete command-line being used to compile your config.c file?

JoeCFD

@JonB with flag -x gcc will work for c++ code as well. But it is better to separate c and c++ code with .c and .cpp

SPlatten

This post is deleted!

SPlatten

This post is deleted!