[Windows] BCB6 C++ / Dev c++ / MinGW linker issues

Solutions to common issues, problems, frequently asked questions.

[Windows] BCB6 C++ / Dev c++ / MinGW linker issues

Postby tictactouc » Fri Jul 22, 2005 5:12 am

Hello Brett, in my programs, C++ Interface is better than C interface with my Borland C++builder6 compiler.
How can I do to export the fmodex.dll symbols for the C++Builder6 compiler.
I hope really that it's possible.
Even if it's complicated, I'm ready to do this.

Thanks for all!!!
tictactouc
OldSk00l
 
Posts: 29
Joined: Sun May 23, 2004 8:29 pm

Postby tictactouc » Fri Jul 22, 2005 11:08 pm

brett wrote:you cant use C++ interface on the non MS compilers.
The C++ symbols in the DLL for C++ are mangled in a way that cannot be compatible, becausee there is no standard like there is with simple C stdcall name mangling.
To fix it we would have to change our API to make the C++ interface a wrapper of the C interface, with extra call overhead and I don't want to do this. The other compilers just aren't popular enough compared to msvc/.net. You can still use the C interface though.
Hello Brett, it's a pity, but I'm very happy for Fmod Ex.
Thanks for all!!!
tictactouc
OldSk00l
 
Posts: 29
Joined: Sun May 23, 2004 8:29 pm

Postby Electron » Sun Oct 16, 2005 11:15 am

What the heck is the point of libfmodex.a then? Obviously I'm missing something here
Electron
Newbie
 
Posts: 6
Joined: Sun Oct 16, 2005 11:13 am

Postby Janus » Sun Oct 16, 2005 2:09 pm

Electron wrote:What the heck is the point of libfmodex.a then? Obviously I'm missing something here
It lets you use FMod Ex?
Janus
Elite
 
Posts: 315
Joined: Wed Nov 21, 2001 11:00 am
Location: Issaquah, WA

Postby Electron » Sun Oct 16, 2005 11:59 pm

I apolgize for my stupidity. I did not realize there still was a C api, there is virtually no mention of it in fmodex.chm. Imho, it would be a good idea for the Platform Specific Issues section of the chm to mention, in the section discussing which library to use, that the C++ API is not accessible from mingw or Borland and that there still is a C API containing full functionality. Admittedly, I would have known that a C api still exists if I had read the Introduction page of the chm, so that is clearly my fault. The fact that mingw and Borland users cannot access the C++ api is not mentioned anywhere in the doc that I could find (please let me know if I'm missing I'm being unobservant again), and is not in the least obvious. Since a .a library was provided, I assumed that there was full support for mingw. If you do not wish to provide full mingw support it would be nice if the fact were better documented.


To fix it we would have to change our API to make the C++ interface a wrapper of the C interface, with extra call overhead and I don't want to do this.

Or you could provide a version of the dll compiled with mingw. Considering that fmod.dll is under 300 kb, this would hardly increase download size.

Anyway, thanks for providing fmod. I aplogize for my tone. Discovering that I can't link the project I ported from fmod 3 to fmodex c++ api is just kinda frustrating.
Electron
Newbie
 
Posts: 6
Joined: Sun Oct 16, 2005 11:13 am

Postby Bruce » Fri Nov 18, 2005 8:23 am

brett wrote:To fix it we would have to change our API to make the C++ interface a wrapper of the C interface, with extra call overhead and I don't want to do this.


Umm... I just realized this, but why would there be any more overhead than there is now? I'm guessing based on the way you're talking about it that the C interface is currently a wrapper for the C++ interface--changing it around so that the C interface is the native one and the C++ one wraps it wouldn't add any extra overhead. If it's currently the other way around (C++ wraps C), then fixing the issue is child's play--just move the wrapper classes into fmod.hpp.

I mean, I can't imagine that you duplicated (i.e. copied & pasted) every function in the C API that's implemented in the C++ API--that would be a maintenence nightmare!

Of course, the issue doesn't affect me personally because I use Visual C++ (and besides the fact, I'm using the C API because I'm more comfortable with it); I'm just saying. Of course, if C++ name mangling was standardized, nobody would have this problem in the first place...

Edit: I just read somewhere that Visual C++ 2005 changes the name mangling rules compared to VC6/7. Yet another reason to make the C++ interface universal--if you can't even support all versions of the same compiler, something should be changed.
Bruce
OldSk00l
 
Posts: 27
Joined: Tue Jan 11, 2005 9:25 am

Postby rolkA » Thu Nov 24, 2005 3:43 am

brett wrote:you cant use C++ interface on the non MS compilers.
The C++ symbols in the DLL for C++ are mangled in a way that cannot be compatible, becausee there is no standard like there is with simple C stdcall name mangling.


Hello, Borland C++ Builder 2006 is about to be released, so i'm wondering if this C++ interface will be compatible with it, even "one day" (i mean... the interface of the DLL of course).

Thanks, thats a great work anyway.
rolkA
Newbie
 
Posts: 2
Joined: Thu Nov 24, 2005 3:35 am

Postby Bruce » Fri Dec 02, 2005 5:23 am

Ah, okay. Yeah, I guess it would be a pain to change the "native" interface at this stage--not to mention it would break binary compatibility. I was actually under the impression that the exported C++ classes simply called the C API internally (since FMOD 3 was all C functions); I didn't realize that the actual FMOD code was in the classes.

This is the primary reason C is still in widespread use--platform independence. It's why so many cross-platform libraries are written in C (or at the very least, export C-compatible APIs). Since C++ name mangling is not standardized--and there doesn't appear to be any intention to do so--C++ is unsuitable for cross-platform APIs.

None of this means I hold anything against FMOD, of course--more of a grudge against C++. Just keep this post in mind for the next major rewrite of FMOD (assuming there will be another one).
Bruce
OldSk00l
 
Posts: 27
Joined: Tue Jan 11, 2005 9:25 am

Postby rolkA » Thu Dec 15, 2005 12:57 pm

rolkA wrote:
brett wrote:you cant use C++ interface on the non MS compilers.
The C++ symbols in the DLL for C++ are mangled in a way that cannot be compatible, becausee there is no standard like there is with simple C stdcall name mangling.


Hello, Borland C++ Builder 2006 is about to be released, so i'm wondering if this C++ interface will be compatible with it, even "one day" (i mean... the interface of the DLL of course).

Thanks, thats a great work anyway.


So i guess the answer is "no" ? thats a pity :cry:
rolkA
Newbie
 
Posts: 2
Joined: Thu Nov 24, 2005 3:35 am

Postby djmaze » Thu Dec 29, 2005 5:18 am

Hmm i did try by modifying fmod.hpp

Changed all
Code: Select all
FMOD_RESULT F_API

into
Code: Select all
virtual FMOD_RESULT


But any function call after the System_Create() fails :cry:
djmaze
Elite
 
Posts: 196
Joined: Wed Oct 30, 2002 6:46 am
Location: Netherlands

Postby djmaze » Sat Dec 31, 2005 12:26 pm

brett wrote:why did you do that?

You are using C++ classes in the dll and I know you can't mix C++ classes between vendors due to the different name mangling and object creation schemes that prevent this.

So instead i was trying to explicitly call them based on the following resources i've read.

http://www.codeguru.com/Cpp/W-P/dll/imp ... e.php/c123
http://www2.linuxjournal.com/article/3687

I've made an example by building database wrappers.
The DLL's are compiled using MSVC 6 and i've compiled 2 executables (1 MSVC and 1 BCB 4)
The class inside the dll worked in both cases thanks the to the virtual keyword to allow derived classes.

Shure i know you could override virtual functions but it was the only way for me to build a C++ Classes workspace with dynamic dll's
This solution provided me a huge flexibility in my musicplayer application to offer several database engines and not having the overhead to be bound to have them all installed and loaded. Afterall you're only using one database anyway.
May the sound be with you!
--------------------------------
Win 2k lite, Terratec EWX24/96 & DMX 6 Fire LT, Marian Marc 4 Digi, Pentium 4 2.53, 512 MB DDR 333, Intel D845PESV mobo
djmaze
Elite
 
Posts: 196
Joined: Wed Oct 30, 2002 6:46 am
Location: Netherlands

What version of VC++?

Postby parente » Sat Dec 31, 2005 6:04 pm

With what version of Visual C++ is the fmodex_vc.lib compiled? Maybe I'm missing it, but I don't see that key piece of information in the documentation.
parente
Newbie
 
Posts: 9
Joined: Thu Jul 22, 2004 3:13 am

Postby slajar » Sat Feb 04, 2006 10:00 pm

Hi everybody,

I think there is a solution to this problem. Since FmodEx is not object oriented it is object based code (no object creation by the user and no inheritance). This is good, because someone can write a wrapper to this. You just need to write the same class wrapper as it exits for C# in C++ and the it's compilable with every C++ compiler even with visual C++ too ;) The basic principle behind the c# interface is to encapsulate the pointer to the c-structs in new C++ objects. With this technique you can get the exactly the same interface as it is with Visual C++.

best regards
Sl@jaR
slajar
Elite
 
Posts: 86
Joined: Mon Jan 31, 2005 8:10 am

Postby djmaze » Thu Mar 02, 2006 4:36 pm

Electron wrote:Or you could provide a version of the dll compiled with mingw. Considering that fmod.dll is under 300 kb, this would hardly increase download size.

brett wrote:there are about 4 or 5 compilers out there, mingw isnt the only one so it would be a real pain for us to maintain and support 8-10 dlls


We could do that for you :)
For example i use FLTK to start a new cross-platform music player using F-Ex and i would love to see a GCC compiled version on X11, Win32 and OSX
djmaze
Elite
 
Posts: 196
Joined: Wed Oct 30, 2002 6:46 am
Location: Netherlands

Tutorial for the C Interface (for example on Dev-C++)

Postby Hurix » Fri Jun 02, 2006 2:18 am

So, if i can't use the C++ interface from the .chm's tutorial i have to use the C interface.
Do you have a tutorial for me like the one in the .chm?
Or just an example of initalising the System and playing a Soundfile?

[edit]
Well ok, no i found out that the functions of the C interface have the same name like the C++ interface methods have. So if you have an object of FMOD::System in C++ you need a FMOD_SYSTEM in C.
Then the code for the tutorials first example look like:
Code: Select all
/* deklaration */
FMOD_RESULT result;
FMOD_SYSTEM *system;

/* create the system */
result = FMOD_System_Create(&system);
if (result != FMOD_OK)
{ /* check for an error */
    printf("FMOD error! (%d) %s\n", result, FMOD_ErrorString(result));
    exit(-1);
}

/* init the system (fourth parameter at first place to pass the system!) */
result = FMOD_System_Init(system, 100, FMOD_INIT_NORMAL, 0);
if (result != FMOD_OK)
{ /* check for an error */
    printf("FMOD error! (%d) %s\n", result, FMOD_ErrorString(result));
    exit(-1);
}

Right? So i wonder if the rest differs much more then this...

At least, I just always get this:
`FMOD_ErrorString' undeclared

And I can't find my mistake, where is this function deklared or defined?
Hurix
Newbie
 
Posts: 5
Joined: Fri Jun 02, 2006 2:08 am

Next

Return to Knowledge Base

Who is online

Users browsing this forum: No registered users and 0 guests