1

Can someone help me understand why MSVC 12 2013 reports these symbols are unresolved?

Error   239 error LNK2019: unresolved external symbol "public: static double const Wm3::Math<double>::DEG_TO_RAD" (?DEG_TO_RAD@?$Math@N@Wm3@@2NB) referenced in function "protected: void __cdecl Matt::ExternalNavConverter::CExternalNavConverter::DoProcessExternalNav(void)" (? DoProcessExternalNav@CExternalNavConverter@ExternalNavConverter@Matt@@IEAAXXZ)  C:\Users\mrussell\workspace\Matt\build-conan-Release\Libraries\MattClient\ExternalNavConverter.lib(ExternalNavConverter.obj)    MattClient

The symbol DEG_TO_RAD is defined in my Wml.dll file, which I'm quite sure is in my %PATH% when I start MSVC.

The output from dumpbin for the DLL is:

dumpbin /exports C:\Users\mrussell\.conan\data\wml\3.x\ntc\stable\package\a4501f33ae09df332b76b4d6f0e5cebffbe83874\bin\Wml3.dll  | grep -i DEG_TO_RAD
 143   8E 00031A64 ?DEG_TO_RAD@?$Math@M@Wm3@@2MB
 144   8F 00031A98 ?DEG_TO_RAD@?$Math@N@Wm3@@2NB

And for the LIB:

dumpbin /exports  C:\Users\mrussell\.conan\data\wml\3.x\ntc\stable\package\a4501f33ae09df332b76b4d6f0e5cebffbe83874\lib\Wml3.lib | grep DEG_TO_RAD
  ?DEG_TO_RAD@?$Math@M@Wm3@@2MB (public: static float  const Wm3::Math<float>::DEG_TO_RAD)
  ?DEG_TO_RAD@?$Math@N@Wm3@@2NB (public: static double const Wm3::Math<double>::DEG_TO_RAD)

I set up a minimal example showing the failed linking here, unfortunately I'm not sure I can put the headers or .lib file.

I'm not that familiar with dumpbin, I'm more accustomed to nm with c++filt.. But to me, this suggests that the symbol DEG_TO_RAD is exported in the DLL.

In the Linker command line window, I can see that by bin path (path the to DLL) is provided as a /LIBPATH, and the full path to the .lib is provided as well (provided in "Additional Dependencies".)

Could this be because I might be mixing up shared and static libs together? Or a sign that despite me thinking the DLL is in my path, somehow it isn't? Or the symbols in the DLL aren't actually there? (the equivalent of a non-T for the symbol type in nm)

I'm going through the list given in this answer, but so far am just confused as to why it is not working.

Matt
  • 1,928
  • 24
  • 44
  • 1
    This is a linker error, you need to link with `Wml.lib` (the export library for Wml.dll). At the linking stage the linker has no interest in `Wml.dll`. – Richard Critten Apr 08 '18 at 17:01
  • In addition to what Richard says, the Visual Studio project options have a linker settings section where you can specify "additional dependencies". This where you put the name of the LIB file corresponding to that DLL. – E. van Putten Apr 08 '18 at 17:19
  • hey @Richard Critten , yeah, I am linking with `Wml.lib`, and as I said above, `Wml.lib` is specified in my `Additional Dependencies`. I was under the impression though that `.lib`s for shared libraries usually only declared the symbols that are actually defined in the `dll`, so doesn't the DLL have to be find'able in the PATH? In anycase though, yeah, the 'lib' is specified. That's why I'm so confused. – Matt Apr 08 '18 at 17:56
  • 1
    Yes the DLL needs to be find-able at __runtime__. However `LNK2019` is a link time error. – Richard Critten Apr 08 '18 at 18:22
  • Alright, so I still have no idea why it won't link then. The symbols are in the lib, the `.lib` is specified as a link target, the symbols in the error match the symbols in `dumpbin`. :( – Matt Apr 08 '18 at 18:31
  • Well, the .`lib` already in the *Additional Dependencies*, and if the `DLL` isn't required at all during linktime, then moving the DLL shouldn't make any difference? I can give the `#pragma` recommendation a go though. – Matt Apr 08 '18 at 18:36
  • Possible duplicate of [Linking dll in Visual Studio](https://stackoverflow.com/questions/7845886/linking-dll-in-visual-studio) – Robert Andrzejuk Apr 08 '18 at 18:37
  • I still really don't think it's a duplicate, as as the question states, the lib is an *Additional Dependency*, but it's still throwing a linking error. – Matt Apr 08 '18 at 18:38
  • Did you try this? https://msdn.microsoft.com/en-us/library/ms235636.aspx – Robert Andrzejuk Apr 08 '18 at 18:49
  • A [mcve] would be very helpful. – Robert Andrzejuk Apr 08 '18 at 18:51
  • Is the .lib file in the same folder as the .dll? Do you get any other errors or messages from the linker? – 1201ProgramAlarm Apr 08 '18 at 19:22
  • Hi @RobertAndrzejuk, I posted a [minimal working example here](https://gist.github.com/kheaactua/bcee42148faa063655c5042102938a1f), you won't be able to build it without the WML source though, I'm awaiting approval to see if I can upload it. (we've tweaked out version of WML, so you can't just download it from the original site.) – Matt Apr 09 '18 at 13:18
  • @1201ProgramAlarm No, right now I have it laid out such that the `.lib` is in `/lib`, and the `.dll` is in `/bin`. My error it self is a linker error (`LNK2019`), doesn't that mean it's from the linker? I'm more familiar with g++ where you can see from the output whether the error derives from the compiler or linker, I'm not sure how to see that difference with MSVC. – Matt Apr 09 '18 at 13:21
  • @RobertAndrzejuk Hey, the original project (not the minimal working example) relies on tonnes of DLLs. Normally they're easy to link against, it's simply this one DLL that I have trouble with. I suppose my ultimate question is that, given the output from `dumpbin`, and that the lib is specified as an `Additional Dependency`, why can't it link? What could be special about this lib that blocks it? Given the `dumpbin` output, is there even room for something to go wrong? – Matt Apr 09 '18 at 13:24

1 Answers1

1

The issue was that while the WML symbols were exported properly with __declspec(dllexport), they weren't being imported properly by my app.

In the minimal working example I added a snippit of Wm3Platforms.h where dllexport and dllimport are declared. Typically (in my experience) at least, these are controlled by a single preprocessor definition (if on, do dll_export, if off, do dll_import), but this code demands WM3_DLL_IMPORT is declared to make it importable.

Declaring WM3_DLL_IMPORT fixed my issue.

So, turns out my issue was specific to this lib's source code....

Matt
  • 1,928
  • 24
  • 44