I am trying to upgrade from FMOD 4.30.05 to the latest 4.40.00. It compiles and links with minimum number of changes, however when I go to run it I get a popup dialog with the message:
[quote:2auzroy7]The procedure entry point ?getDriverCaps@System@FMOD@@QAG?AW4FMOD_RESULT@@HPAIPAH1PAW4FMOD_SPEAKERMODE@@@Z could not be located in the dynamic link library fmodex.dll[/quote:2auzroy7]
FYI, I am compiling with VS2010 32-bit build and am linking against fmodex_vc.lib, but the same error occurs with fmodex64_vc.lib and fmodex64.dll in 64-bit build.
Interestingly if I "dumpbin /exports fmodex.dll", I see a slightly different symbol being exported:
[code:2auzroy7] 71 46 0006EC40 ?getDriverCaps@System@FMOD@@QAG?AW4FMOD_RESULT@@HPAIPAHPAW4FMOD_SPEAKERMODE@@@Z[/code:2auzroy7]
Now if I use the Visual Studio "undname" tool to demangle the names, it is clear that the signature does not match:
i.e. fmodex_vc.lib is looking for this symbol:
[code:2auzroy7]public: enum FMOD_RESULT __stdcall FMOD::System::getDriverCaps(int,unsigned int *,int *,int *,enum FMOD_SPEAKERMODE *)[/code:2auzroy7]
however, this symbol is exported from fmodex.dll:
[code:2auzroy7]public: enum FMOD_RESULT __stdcall FMOD::System::getDriverCaps(int,unsigned int *,int *,enum FMOD_SPEAKERMODE *)[/code:2auzroy7]
Either I have missed something or am doing something wrong (very likely!) or there is a bug in fmodex_vc.lib that is trying to resolve the incorrect DLL symbol. My guess is I suspect the implementation of getDriverCaps() is looking up the wrong DLL entry point signature.
Can someone please check if this is the case? BTW I get the same error with the 4.38.xx version too, but it does not appear to affect earlier versions that don’t have the separate 64-bit fmodex64.dll included (but is why I need to upgrade in the first place!). If it is a bug I’m not sure why this problem does not appear to have affected anyone else.
Thanks for your help.
- mcnab asked 5 years ago
are you absolutely 100% sure you haven’t accidently linked to the 4.30 import library? It seems very likely this is what the issue is. Make sure you delete every trace of fmod_vc.lib – none of the examples would compile/run if the dll/libs were mistmatched within the sdk.
Following your suggestion, I removed every copy of fmodex_vc.lib from my entire system except for the one in 4.40.00, only to find that I still got the same error (!!)
Some more investigation revealed the cause of the problem (in case anyone else encounters a similar issue in the future):
As it happens we are also linking to Teamspeak libraries (ts3client_win32.lib and ts3server_win32.lib). This particular version of Teamspeak appears to be using FMOD internally (version 4.31.2 I think). Despite us explicitly linking to the 4.40.00 fmodex_vc.lib, the linker was finding FMOD symbols in the Teamspeak libraries, and hence attempting to load the incorrect DLL symbols.
Remove Teamspeak libraries and problem solved! 😀
- mcnab answered 5 years ago
Please login first to submit.