0
0

Hi,

This might fall outside the scope of fmod but I have a feeling it’s something simple that a bunch of you already know. Please forgive me if the solution is painfully obvious — I come from a Windows programming background so there’s a lot of stuff I don’t know about Mac OS X / Linux development.

My problem is that when compiling programs that use fmod and single precision math functions, I get linker warnings like this:

[code:35q1r8oj]
ld: warning multiple definitions of symbol _sinhf
/usr/lib/gcc/darwin/3.3/libstdc++.a(stubs.o) private external definition of _sinhf in section (__TEXT,__text)
/usr/lib/libSystem.dylib(floating.o) definition of _sinhf
[/code:35q1r8oj]

I’m guessing this is because fmod and the program are both statically linking to libstdc++ causing the multiple definition. How do I properly compile/link the program so that this doesn’t happen or so that I don’t get these warnings?

The warnings are easy to duplicate, just edit the playsound example to #include <math.h> then invoke a single precision math function, for example: printf("hi %f\n",sinf(0.3f)); Then execute the makefile.

I am using Mac OS X 10.3.9 (ppc) using FMOD 4.08.09 and gcc 3.3 (came with XCode 1.5).

Any help greatly appreciated!

-j

  • You must to post comments
0
0

If you take a look at the 3d example, it uses the sin() from the maths library. Do you have any problems simply using make on the makefile for that example?

  • You must to post comments
0
0

Hi Mathew,

Double precision math functions like sin(), cos(), tan() work fine, it’s the single precision ones like sinf(), cosf(), tanf() that give me the warnings.

In the 3D example, if you change the sin() function call to sinf(), then I get the warnings again.

Also, it seems that the code runs fine on mac’s that have newer versions of gcc/xcode. I was able to compile my program fine on my friend’s computer with no warnings. So I’m guessing this is because I have a really old version of gcc. Something I have to live with?

-j
ps: highly doubtful but maybe it’s cause my friend’s mac is an intel? don’t see how that would change anything though, but thought I’d mention it to be thorough.

  • You must to post comments
0
0

That is interesting, I tried the same thing here on our PPC mac using sinf() in the 3d example and I get no warnings. That machine was set to use GCC 3.3 also. I am uncertain as to why compiling the same code, using the same version of GCC would cause different results. I assume you are just running the make file shipped with FMOD 3d example? The only thing that comes to mind is something with the way XCode 1.5 setup things.

One interesting thing to note is with GCC 4.0 a change was introduced that instead of statically linking the libstdc++ library it dynamically links it. When we do a release here we lipo the x86 version created with GCC4.0 and the PPC version created with GCC3.3 into a universal binary.

If the conflicting symbol is coming from FMOD then that implies that the FMOD dylib is exposing that symbol (which on PPC is should not be). I have just confirmed this at our end, I suggest you change to the directory where you have libfmodex.dylib and type the following:

[code:lnduk51h]
nm libfmodex.dylib | grep sinf
[/code:lnduk51h]

If you don’t get any matches (and you shouldn’t) then your conflicting symbol isn’t coming from FMOD.

Cheers,

  • You must to post comments
0
0

Yup, I used the makefile that was included with FMOD to compile the 3D example. Also, running "nm libfmodex.dylib | grep sinf" returned no matches as you expected.

Hmm, on closer examination of the warnings, it seems it’s between libstdc++ and libSystem.dylib. Weird! Maybe I need to reinstall Xcode or something…

-j

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.