# FMOD Studio API Support for Windows MinGW gcc?

**URL:** <https://qa.fmod.com/t/fmod-studio-api-support-for-windows-mingw-gcc/11327>\
**Category:** FMOD Studio\
**Created:** [March 12, 2014, 10:53pm UTC](https://qa.fmod.com/t/fmod-studio-api-support-for-windows-mingw-gcc/11327 "2014-03-12T22:53:11Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![DaleKim](https://avatars.discourse-cdn.com/v4/letter/d/c5a1d2/32.png) [@DaleKim](https://qa.fmod.com/u/DaleKim)\
**Post date:** [March 12, 2014, 10:53pm UTC](https://qa.fmod.com/t/fmod-studio-api-support-for-windows-mingw-gcc/11327/1 "2014-03-12T22:53:11Z")

</div>

I’ve been getting started on FMOD integration for a game I’m working on and I noticed that FMOD Studio API 1.03.00 does not seem to have binaries that are compatible with MinGW gcc. Do such binaries exist? If so, is there a way for me to get a hold of them?

It’s pretty critical for me to get a gcc compatible set of binaries because our engine code is cross platform and depends highly on a specific set of C++11 features that are not yet implemented (to the best of my knowledge) in Microsoft’s compiler.

---

<div class="post-metadata">

**Author:** ![brett](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/brett/32/261_2.png) [@brett](https://qa.fmod.com/u/brett)\
**Post date:** [March 17, 2014, 12:06am UTC](https://qa.fmod.com/t/fmod-studio-api-support-for-windows-mingw-gcc/11327/2 "2014-03-17T00:06:51Z")

</div>

You should be able to get this working. In FMOD Ex we used to run cygwin’s ‘DLLTOOL’ which produced an import library from a dll. Because fmod studio exports C symbols, you can do it this way, and you’re restricted to the C api not c++ (because the ABI between MSVC and CYGWIN are not compatible with c++).  
Here’s the commandline we used for fmodex and cygwin

…\bin\cygwin\dlltool --output-lib “…\version\api\lib\lib$(TargetName).a” -A -k --dllname $(TargetFileName) --def …\src\fmod\_cygwin.def

I added what I see is still exported by studio’s build process, the cygwin .def file for the low level. The studio api doesnt have it yet but we can produce that.  
As a test, let me know if this works and we can continue.

---

<div class="post-metadata">

**Author:** ![DaleKim](https://avatars.discourse-cdn.com/v4/letter/d/c5a1d2/32.png) [@DaleKim](https://qa.fmod.com/u/DaleKim)\
**Post date:** [March 20, 2014, 2:40am UTC](https://qa.fmod.com/t/fmod-studio-api-support-for-windows-mingw-gcc/11327/3 "2014-03-20T02:40:44Z")

</div>

Brett,

I generated libfmod.a for the low level using dlltool and the .def you provided, and it seems to work! I did, however, hit a snag where it seems like the preprocessor was picking up a wrong set of #defines for some calling conventions in fmod\_common.h.

```auto
...

In file included from c:\mingw\include\fmod\fmod.h:14:0,
                 from test.cpp:1:
c:\mingw\include\fmod\fmod_common.h:1115:33: error: expected ')' before '*' token
 typedef FMOD_RESULT (F_CALLBACK *FMOD_SYSTEM_CALLBACK) (FMOD_SYSTEM *system, FMOD_SYSTEM_CALLBACK_TYPE type, void *commanddata1, void *commanddata2, void *userdata);
                                 ^
c:\mingw\include\fmod\fmod_common.h:1117:33: error: expected ')' before '*' token
 typedef FMOD_RESULT (F_CALLBACK *FMOD_CHANNELCONTROL_CALLBACK) (FMOD_CHANNELCONTROL *channel, FMOD_CHANNELCONTROL_TYPE controltype, FMOD_CHANNELCONTROL_CALLBACK_TYPE callbacktype, void *commanddata1, void *commanddata2);

...
```

Looking at the preprocessed source, I see the following:

```auto
...

typedef FMOD_RESULT (_stdcall *FMOD_SYSTEM_CALLBACK) (FMOD_SYSTEM *system, FMOD_SYSTEM_CALLBACK_TYPE type, void *commanddata1, void *commanddata2, void *userdata);

typedef FMOD_RESULT (_stdcall *FMOD_CHANNELCONTROL_CALLBACK) (FMOD_CHANNELCONTROL *channel, FMOD_CHANNELCONTROL_TYPE controltype, FMOD_CHANNELCONTROL_CALLBACK_TYPE callbacktype, void *commanddata1, void *commanddata2);

...
```

Meanwhile, fmod\_common.h contains:

```auto
/*
    Compiler specific settings.
*/

#if defined( __CYGWIN32__ )
    #define F_CDECL __cdecl
    #define F_STDCALL __stdcall
    #define F_DECLSPEC __declspec
    #define F_DLLEXPORT ( dllexport )
#elif defined(WIN32) || defined(_WIN32) || defined( __WIN32__ ) || defined(_WIN64)
    #define F_CDECL _cdecl
    #define F_STDCALL _stdcall
    #define F_DECLSPEC __declspec
    #define F_DLLEXPORT ( dllexport )
#elif defined( __MACH__ ) || defined( __ANDROID__ ) || defined( __linux__ )
    #define F_CDECL
    #define F_STDCALL
    #define F_DECLSPEC
    #define F_DLLEXPORT __attribute__ ((visibility("default")))
#else
    #define F_CDECL
    #define F_STDCALL
    #define F_DECLSPEC
    #define F_DLLEXPORT
#endif
```

Looks like MinGW + gcc is falling into the WIN32 set of defines. I ended up getting around this for the time being by adding #define **CYGWIN32** just prior to including the fmod headers, and now my test program compiles, links, and runs just fine. The preprocessed output looks like so:

```auto
...

typedef FMOD_RESULT ( __attribute__ (( __stdcall__ )) *FMOD_SYSTEM_CALLBACK) (FMOD_SYSTEM *system, FMOD_SYSTEM_CALLBACK_TYPE type, void *commanddata1, void *commanddata2, void *userdata);

typedef FMOD_RESULT ( __attribute__ (( __stdcall__ )) *FMOD_CHANNELCONTROL_CALLBACK) (FMOD_CHANNELCONTROL *channel, FMOD_CHANNELCONTROL_TYPE controltype, FMOD_CHANNELCONTROL_CALLBACK_TYPE callbacktype, void *commanddata1, void *commanddata2);

...
```

As long as I can do something similar to FMOD Studio, even if it’s just the C API, then I should be able to get things up and running!

-Dale Kim