0
0

Perhaps I am asking for the same thing and someone did already, but are we going to get MinGW support? Or will I have to write my own fmod classes wrapper or something? :-)

  • You must to post comments
0
0

I don’t think you even tested it.
I did following and my libfmodex.a works:

1) Created .DEF file WITH “@NN” function postfixes.
2) Used “dlltool -A -k -d fmodex.def -l libfmodex.a”

Then I successfully compiled “3d” example in MinGW.
I tried it only with functions that are in use by this example, but I have no reason to think it won’t work with the rest of functions.

-A option to dlltool means to ADD stdcall aliases without “@NN”. This is why they are needed in .def file even when fmodex.dll doesn’t use them. It don’t work in any other way to me.

  • You must to post comments
0
0

Fantastic! I’ll try it out ASAP.

  • You must to post comments
0
0

I’m having also hard time getting FMOD Ex C++ working under MinGW and while searching for guidande I found this thread. C version works without problems but when trying to link C++ I get just the similar kind of errors.

So, any chance of sharing these .DEF files for the dlltool? Or will the upcoming final release have also libraries that work with MinGW mangling?

  • You must to post comments
0
0

Okay, I’ll change the question to this:
Is there anyone who managed to create FMOD EX import library for MinGW that WORK ???

  • You must to post comments
0
0

I wish it would be that easy 😉

I cannot use C++ interface simply because MinGW uses different name mangling and when FMOD exports e.g. FMOD::Channel::addDSP as “?addDSP@Channel@FMOD@@QAG?AW4FMOD_RESULT@@PAVDSP@2@@Z” (Microsoft mangling?), MinGW expects it to be something like “__ZN4FMOD7Channel6addDSPExxx” (GCC mangling).
This is first problem and that is why I wanted to create myself wrapper class to C functions (just like you do for C#).

Okay, let’s see C
The second problem is that FMOD uses STDCALL for C function but exports function names without @n postfix. And code from MinGW expects STDCALL function to have this. So I had to recreate .DEF (and then import library) file for fmodex.dll with function aliases that includes @n. I actually did this only for few functions to see some FMOD examples to compile.

  • You must to post comments
0
0

I haven’t defined any C++ exports as I don’t expected it to work.
I tried C functions only, but I’ll look if there is way to get C++ exports work. I don’t see much into it but there may be way to get it work as aliases.

I’ll check the def file and be right back…

  • You must to post comments
0
0

Unfortunately your libfmodex.a do not work …at least for me :-(
Seems that you are still missing the @N aliases for STDCALL functions.

For example: you are exporting “FMOD_System_Create” but at least you should export “FMOD_System_Create@4” alias for this symbol (in import library). This mean to write “FMOD_System_Create@4” into .DEF file and compile into import library with “-A -k” dlltool options. I am not sure how it works, but it works for me.
My .DEF file contain “FMOD_System_Create@4” export symbol and it is compiled into .a import library by “dlltool -A -k -d fmodex.def -l libfmodex.a” command. This defines also non-@N symbols and finally links correctly.

I haven’t tried other compilers, but I think that making fmodex.dll to export stdcall symbols with “@N” postfix would make life on windows easier :-)

One more thing, wouldn’t be better to change line 45 of fmod.h from
[code:13noptwy]#define F_API F_STDCALL[/code:13noptwy]
to
[code:13noptwy]#define F_API __declspec(dllimport) F_STDCALL[/code:13noptwy]
???

  • You must to post comments
0
0

[quote="brett":amx58dyc]yes C functions should work.

I think i’ve just solved the C++ issue.
in our def file we can put

CPP_FMOD_System_Init = ?init@System@FMOD@@QAG?AW4FMOD_RESULT@@HHW4FMOD_INITFLAGS@@PBX@Z

for example and it generates a different symbol to the msvc export.
problem here being is i don’t think cygwin will accept that symbol, it will want a cygwin style mangled name. This could cause real headaches as we would need to know how cygwin mangles its c++ names.[/quote:amx58dyc]

It is very sad for me to say that, but wouldn’t it be better to export only “C” functions and leave all the C++ stuff to HPP header files?

You would save some kilobytes in the DLL and the C++ interface would get MUCH more friendly to all C++ compilers.

  • You must to post comments
0
0

[quote="brett":fndjyij5][quote="Tringi":fndjyij5]

One more thing, wouldn’t be better to change line 45 of fmod.h from
[code:fndjyij5]#define F_API F_STDCALL[/code:fndjyij5]
to
[code:fndjyij5]#define F_API __declspec(dllimport) F_STDCALL[/code:fndjyij5]
???[/quote:fndjyij5]

No, this isn’t nescessary, and avoids us having to do extra #ifdefs if you want to use fmod statically (ie source code licensees).

anyway about the symbols,
We use the ‘simple’ .def file format so it makes for easy dynamic linking. This helps for VB and delphi.

I’ll try and export the cygwin/mingw lib again, this time with @xx in the symbols.

edit: ok try this http://52.88.2.202/files/libfmodex.zip[/quote:fndjyij5]

Still not working :-(
Seems that there is mismatch in number of underscores in function prefixes.

If you use “dlltool” to create the import library, use -U (or remove if used) option to fix this.

  • You must to post comments
0
0

[quote="brett":1f64fwir][quote="Tringi":1f64fwir][quote="brett":1f64fwir]yes C functions should work.

I think i’ve just solved the C++ issue.
in our def file we can put

CPP_FMOD_System_Init = ?init@System@FMOD@@QAG?AW4FMOD_RESULT@@HHW4FMOD_INITFLAGS@@PBX@Z

for example and it generates a different symbol to the msvc export.
problem here being is i don’t think cygwin will accept that symbol, it will want a cygwin style mangled name. This could cause real headaches as we would need to know how cygwin mangles its c++ names.[/quote:1f64fwir]

It is very sad for me to say that, but wouldn’t it be better to export only “C” functions and leave all the C++ stuff to HPP header files?

You would save some kilobytes in the DLL and the C++ interface would get MUCH more friendly to all C++ compilers.[/quote:1f64fwir]

I’m sorry this doesn’t make sense, what’s wrong with exporting a C++ interface?
If you mean we should be using the VTable interface, then that’s not poissible. We use a mangled this pointer for channel reference counting, and if that went to a vtable it would crash.
Also checking ‘this’ before actually using it allows us to check for invalid handles (freed pointers etc). Because of this the symbols need to be linkable like they are with C functions.[/quote:1f64fwir]

I was just thinking if exporting C++ interface is necessary at all, because there may be similar problems with other C++ compilers.

  • You must to post comments
0
0

According to FMOD Ex beta 1:

I am curious why is libfmodex.a trying to link against versionapi?modex.dll instead of fmodex.dll.
And it still seems to be linking to symbols with “@N” appended.

  • You must to post comments
Showing 11 results
Your Answer

Please first to submit.