mercredi 8 juillet 2020

Unresolved external symbols (LNK2001) are clearly found in .obj file

Let's say there is class A and class B.
Class A has a number of of private static data members and implements some getters for those, so they can be read but not written from the outside.
Class B includes A.h, but does not make any calls to A's methods.
Note that these classes are both part of their own dlls respectively. Class A is, as a whole, labelled __declspec(dllexport) so it should be visible.

Building this in Visual Studio is no problem.
My Company needs me to build with an in-house script too, but that doesnt work.
I think that script is based around gms-make but I'm not sure. I also don't know what compiler or linker is being used there.

Throwing this thing into our script gives me LNK2001: unresolved external symbol in B.obj.
The symbols that cannot be resolved are the private static data members inside class A.
When I look at the symbols of B.obj using DUMPBIN, I can find all of these symbols.
(I'm not quite sure whether they're supposed to be there or not, but they are.)

What's more is that another class, class C, living in yet another dll, can import all the information needed from class A. Both in VS and in our script, even though the setup is the same as with class B.

Removing #include "A.h" from B.cppmakes the linker happy again, but I need to use that include there.

I'm told the problem is not with the linker but with my code, so what could I be doing wrong?
Also why does class B try to resolve symbols to private members of another class? Shouldn't those be invisible?

Aucun commentaire:

Enregistrer un commentaire