0
0

I found out several issues with the linux version of FMOD:

1) "Make install" will copy only the version-specific named library file in /usr/local/lib (for example libfmodex-4.32.00.so) and does not copy the symbolic link to it (libfmodex.so). This means that an user must install the specific version of FMOD used to compile the application instead to be free of installing any later version and let the application check FMOD version at runtime and decide if it can use it or not.
I have also not understand if the library file is supposed to be shipped with the application and this is the reason why "make install" would not copy the symbolic link in /usr/local/lib. If this is the case, it’s a bad decision because if you ship your application in source-code form you would NOT distribute any kind of binary with it nor any kind of external library, letting the user download the dependencies by himself.

2) There is absolutely no way in wich FMOD can be compatible with GNU autotools. I wrote a simple makefile.am and I have to link against "libfmodex-4.32.00.so". This mean that when you will release a new FMOD version, an user that download my application need to manually change "libfmodex-4.32.00.so" to the new "libfmodex-4.33.00.so" (for example), and this should not happen. This is due to the fact that there is no symbolic link libfmodex.so in /usr/local (see 1) and especially no tools to investigate the installed FMOD library.

There is no way in wich you can check, for example, FMOD version or FMOD header file presence, usability and path in the configure file of your application.
Please consider build an application like "wx-config", the application built by the wxWidgets project for linux. It consist in a binary application (called wx-config) and a m4 script for autoconf. In your configure.ac file, you will include the m4 script provided by them (wich will in turn call wx-config) and you simply call a function that return you the wxWidgets version, and with another function you will get wxWidgets header files path.

Please build a similar system for FMOD. Checking the FMOD header presence is not a problem, but there is no way in wich autoconf can be aware of FMOD version or the library name to link.

  • You must to post comments
0
0

FMOD doesn’t have complete binary compatibility going forward. Our policy is to maintain ABI on a per stable branch basis, so 4.28.01 and 4.28.10 are binary compatible. In between branches or any two versions of a development branch are not guaranteed to be binary compatible.

We generally recommend app developers ship the version of FMOD they used with their app using local linkage (i.e. FMOD next to the executable). If you wish to have it installed to the machine separately the fully qualified version is used to avoid any ABI compatibility issues. Past versions of FMOD can be downloaded from http://52.88.2.202/index.php/download/find if you do not wish to ship FMOD with your source.

  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.