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.cpp
makes 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