I get following linker error trying to build a project I am trying to integrate fmod with. This is a Visual Studio .NET 2003 environment. I’ve got the fmodex_vc.lib library setup for the project settings but still these errors seem to persist. Any thoughts on what might be the cause here?
[quote:3675anzo] error LNK2019: unresolved external symbol _FMOD_System_Create referenced in function "enum FMOD_RESULT __cdecl FMOD::System_Create(class FMOD::System * *)" (?System_Create@FMOD@@YA?AW4FMOD_RESULT@@PAPAVSystem@1@@Z)[/quote:3675anzo]
- RobSegal asked 11 years ago
You are right. The 3D example project in FMOD does not set stdCall in the project, yet it functions. I have not touched any of the FMOD files so the defines are intact.
Something is strange, though. If I comment out the following:
#define F_CDECL _cdecl
#define F_STDCALL _stdcall
#define F_DECLSPEC __declspec
#define F_DLLEXPORT ( dllexport )
I get no additional errors. It seems the #else below is the one being used, and I’m definatly on Win32.
[size=150:446inbtb][b:446inbtb]Edit:[/b:446inbtb][/size:446inbtb] [b:446inbtb]Forcing Win32 in the Preprocessor did the trick! Odd that it is required, but works nevertheless. Thanks alot Brett for giving me a bone.[/b:446inbtb]
Nothing, it was blank. I took our zLib static library project and just copied it into a new one, and it obviously did not contain any defines. I did it to see if we could get FMOD to finally compile together with our engine. So the project was not created by VS.
I must have overlooked the preprocessor when comparing against the FMOD 3D Example. Now to work around the memory managing stuff Thanks again!
i’m getting a linker error when i try to use FMOD::Memory_GetStats … I am definitely defining WIN33 in my preprocessor settings and my calling convention is _cdecl. i can use FMOD::EventSystem_Create with no problem.
i’m also using vs 2003
- dave7L answered 11 years ago
Yeh the examples build fine. It looks like it’s an issue with my custom project. I’ve developed a workaround which is to isolate fmod in a DLL which I then link to my project. It’s not the ideal solution in my mind but it does keep everything isolated and in the end it gets my what I need so I’m happy. Thanks for the reply brett.
You certainly could have something there brett. Certainly the project settings in Visual Studio note to use __cdecl as the calling convention. That could be it. I’m going with my alternate plan for now as I’m pressed for time but I will look into it at a later date.
We too have the same problem with our custom project, while the examples build fine. Turned out to be the cdecl stuff, but the existing code will not work without it.
I recall there was a way to override these calling conventions.
fmod’s header declares F_API to stdcall because thats what the symbols in the dll are. The default setting in your project is irrelevant.
elif (defined(WIN32) || defined(WIN32) || defined(_WIN64) || defined(_XBOX))
#define F_CDECL _cdecl #define F_STDCALL _stdcall
is the important bit, so maybe you have undef’ed one of the required symbols listed there
Please login first to submit.