I have been using fmod 3.74 for quite some time and have recently transfered over to fmodex on the PC and I have to say it is a real pleasure to work with!
I am doing the same thing at the moment for the Mac and I realize that unlike the 3.74 mac release fmodex comes as dylibs.
This is quite a pain for me for a couple of reasons.
1: I like to compile the x86 and PPC libs into one universal fmod lib for distribution convenience and I can’t really do that with dylibs.
2: I like to keep my code and libs local to the folder I am developing in and dylibs require to be put in a specific and know location.
Any chance you could include static libs for fmodex?
In the next release of FMOD for Mac the internal dylib name has been changed to "./libfmodex.dylib". So now it should be just a matter of compiling the dylib into your executable and doing the following:
[code:2ua3fwsk]install_name_tool -change ./libfmodex.dylib your_install_path/libfmodex.dylib your_executable_name
"your_executable_path" can be a relative path so you can keep your application and associated libs together, no need for a specific install directory.
This is the same approach taken by the FMOD examples if you take a look at the example Makefiles.
It isn’t really necessary to ship a static version of the library since it is pretty common practice to use install_name_tool on Mac.
Thanks for the lipo tip! It would still be nice to have the option of a static link as well. It would save me from having to have this gnarly script run in my build process.
http://ynniv.com/blog/2006/02/deploying … n-mac.html
So Brett, any chance of a static mac lib for fmodex (same as the 3.74 release)?
After looking through Apple Documentation and several posts it seems that the only way to use dylibs in a bundled app is by running a script after the linking process. (see bellow)
It would be really helpful if the OS X download came with both the static and the dylibs of fmodex.
If it was as easy to use a dylib as it is a dll in windows there would be no problem – but considering the number of hoops you have to jump through, it would be nice to let the developer choose what best suits their needs.
From: http://developer.apple.com/releasenotes … s/RN-dyld/
Every mach-o final linked image can contain any number of LC_LOAD_DYLIB load commands which the path of a dylib that must be loaded. Usually, it is an absolute path. ….
Currently, ld(1) has no options for directly embedding @loader_path into LC_LOAD_DYLIB load command. Instead, you must post-process your final linked images with install_name_tool.[/quote:1vkndvto]
Please login first to submit.