the current fmod for linux seems to have been built using gcc 3.0. is it possible to provide builds for gcc 3.3.5 and 4.x ( e.g. 4.1.0 )?
we have some problems atm using gcc 3.3.5, fmod may be one reason for the problem (wrong exception handling resulting in program termination instead of being catched when compiling wiht -O2).
- boto asked 11 years ago
it may be a bug in gcc self as far i could find out googling in net a while. when building our project with -O2 option then in some situations the exception handling goes wrong. in such situation the __cxa_throw() in fmod library i called and the program gets terminated. i wanted to know if that problem also occurs when fmod is built using gcc 4.
i wonder why gcc links an exception handler into fmod while it is a pure C library, though. you just need to search for the keyword "throw" in fmod lib by typing:
then you will see that gcc puts some throw related functions into fmod which are called when our problem with program termination occurs.
i will build our app using gcc 4 soon and look if the problem still occurs.
btw: to be precise, the problem occurs when a function or method is called by a function or method pointer and it ‘throws’ an exception. gcc seems to generate a wrong rollback mechanism then. our problem occurs in combination with gui button callbacks when they throw an exception.
okay, i beleive the problem is that we were linking in libstdc++ into fmod statically due to some problems with older linux distributions not having libstdc++.so.6
i’ve built a library without the static linking of libstdc++, give that a try and let me know how it goes, it should solve your problem.
you can get the library here:
I think we’ll just distribute the libraries this way now, after some more google reading it seems that linking to libstdc++ is a bad idea anyway. It looks like libstdc++.so.6 is pretty much standard nowadays anyway, If it is a problem we may just distribute a set of libraries that links to libstdc++.so.5 as well.
edit: just did a ldd on the library, looks like it doesn’t even depend on libstdc++ anymore anyway, so it should all be good
the program termination problem still remains, but the backtrace looks much better now: the __cxa_throw() funtion of libstdc++.so.5 is now called instead of that of fmod.
i think the problem is really a bug in gcc 3.3.5. i am going to test the application with gcc 4 and see if the problem still exists. thanks for the effort.
Please login first to submit.