Virtual method in library causes unresovled external
-
I'm using:
- QtCreator 10.0.2
- Qt 6.2.9
- cmake-based projects (since that seems to be the default)
- Windows 10
I have a library (let's call it "LibFoo") which is used by an application (call it "Bar").
LibFoo has a class A with a protected method getParameter(), which has an implementation in class A. This works fine, and when I build Bar, the library LibFoo is successfully linked in - no problems.
But if I simply indicate "virtual" for getParameter(), LibFoo still builds fine but when I build Bar, it complains of an unresolved external "protected: virtual unsigned short __cdecl A::getParameter(void) <mangled name>".
More context: A is used as a base class for two others (B and C) within LibFoo, but is not used as the base of any classes in the application Bar.
The thing is, A has other virtual methods. These don't seem to cause problems. It doesn't seem to matter whether those other methods have overrides in B and C.
Furthermore if I create overrides of getParameter in B and C, then the complaint about A::getParameter goes away, but now unresolved external complaints for B::getParameter and C::getParameter show up.
Unfortunately, I can't disclose the actual code in question. More frustrating, I've not been able to reproduce a simplified example that I can post. (My attempt at a "hello" reproduction of the same scenario fails to produce the unresolved external complaints.)
So, I'm just putting my description of the situation out there, in the hopes that someone has run across something similar and knows what might be going on.
Further update: I tried changing the method in question to public instead of protected. That does not make any difference.
-
@Christian-Ehrlicher did you miss "More frustrating, I've not been able to reproduce a simplified example that I can post. (My attempt at a "hello" reproduction of the same scenario fails to produce the unresolved external complaints.)"? :-)
In any case, I discovered the issue: Apparently, moving a project in Qt (maybe only with cmake) is not an obvious operation. In fact, I'm still not quite sure how to do it, what parts of the build directory need to be controlled, etc. But it was rebuilding the library in the OLD build directory rather than the one under the new location of the project.
Gah! Why isn't everything that's project-specific based on relative directories by default!?
-
@dpe3 said in Virtual method in library causes unresovled external:
Unfortunately, I can't disclose the actual code in question.
Then write a simple testcase. Shouldn't be that hard from your description.
Do you properly export the classes?
-
@Christian-Ehrlicher did you miss "More frustrating, I've not been able to reproduce a simplified example that I can post. (My attempt at a "hello" reproduction of the same scenario fails to produce the unresolved external complaints.)"? :-)
In any case, I discovered the issue: Apparently, moving a project in Qt (maybe only with cmake) is not an obvious operation. In fact, I'm still not quite sure how to do it, what parts of the build directory need to be controlled, etc. But it was rebuilding the library in the OLD build directory rather than the one under the new location of the project.
Gah! Why isn't everything that's project-specific based on relative directories by default!?
-