Linux fmod install

[Rowan]

Hi guys. I've been loosely following development of FO since 0.1, and just today saw that 0.3.1 was out, so I thought I'd give it a go, but it turns out I'm a bit inept, and it's not going as planned.

I'd struggled my way to where I thought I had all the dependancies installed, but when I call "scons" in the FreeOrion directory, it complains about fmod, like this:

$ scons configure
scons: Reading SConscript files ...
Configuring for POSIX system...
Checking for pkg-config... ok
Checking for GiGiSDL >= 0.6.0... ok
Checking for log4cpp >= 0.3.4b... failed
Checking log4cpp version == 0.3.4b... yes
Checking for C++ header file log4cpp/Category.hh... yes
Checking for log4cpp::Category::getRoot() in C++ library log4cpp... yes
Checking for fmod >= 3.74... failed
Checking fmod version >= 3.74... no

And now I'm not entirely sure what to do. I have the fmod 3.75 API download, which has a libfmod-3.75.so, and an inc/ folder with a bunch of .h files which look like they might be important. It seems I also have a /usr/lib/libfmod-3.74.1.so, as well. I've tried copying the 3.75 .so to /usr/lib/ with no success, and, well, now I give in and hope some helpful soul here will take pity on my forlorn and broken spirit and tell me what to do.

Ta,
Rowan.

[xscript]

[quote]It seems I also have a /usr/lib/libfmod-3.74.1.so, as well. I've tried copying the 3.75 .so to /usr/lib/ with no success, and, well, now I give in and hope some helpful soul here will take pity on my forlorn and broken spirit and tell me what to do.[/quote]

I think that making a symbolic link from /usr/local/libfmod.so to /usr/lib/libfmod-3.74.1.so should suffice.

You might also run ldconfig as root to update your dynamic libraries list.

To see if all are available, take a look at the output of 'ldd <progname>' and grep for 'not found' or something similar.

[Rowan]

Well, I made a symlink as you suggested and ran ldconfig, but I wasn't quite sure what I was meant to do with ldd, so I did this:

$ ldd libfmod.so
linux-gate.so.1 => (0x008cf000)
libc.so.6 => /lib/libc.so.6 (0x0013c000)
libdl.so.2 => /lib/libdl.so.2 (0x0046f000)
libm.so.6 => /lib/libm.so.6 (0x00111000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00330000)
/lib/ld-linux.so.2 (0x006a3000)

and that didn't mean terribly much to me.

Anyway, running scons in the FO dir failed in the same way as before, so, any further suggestions?

[xscript]

Well, the symlink should be /usr/local/lib/libfmod.so -> libfmod<something>.so, then have a look on /etc/ld.so.conf and check that /usr/local/lib is listed on it (this file tells ldconfig where to look for shared libreries), finally run ldconfig to update the shared object cache (/etc/ld.so.cache).

Once you're done with that, this should work (at least, it worked for me :)).

The 'ldd' thing was to see if the shared library was found on the system, but it's obvius that you won't be able to check it for the existence of libfmod, because you don't have any binary linked against libfmod (you're trying to get this binary!), so forget this.

Maybe a 'strings /etc/ld.so.cache|grep fmod' could help you see if libfmod is available.

If that's not the reason... well, with I don't know how scons internally works, so I don't know how to get its debugging output for each check....

Hope this helps

[thePill]

Well, the symlink should be /usr/local/lib/libfmod.so -> libfmod<something>.so, then have a look on /etc/ld.so.conf and check that /usr/local/lib is listed on it (this file tells ldconfig where to look for shared libreries), finally run ldconfig to update the shared object cache (/etc/ld.so.cache).

Yeah, that's how it should work. The problem is that fmod embed the version numer in the library name instead of using it as a suffix.

So, in build_config.py:
fmod_version = '3.74'

And in SConstruct:
if str(Platform()) != 'win32':
if not conf.CheckLib('fmod-' + fmod_version, 'FSOUND_GetVersion', h\eader = '#include <fmod.h>'):

This will basically perform:
ld -lfmod-3.74
which will fail unless you have *EXACTLY* version 3.74 installed.

A way to resolve this would be to grab the real library version while testing for the library's existance. The python code to do it should be very similar to CheckPkg and CheckVersionHeader respectivly.

But of course, having the authors of fmod deliver a correct library, ie libfmod.so.3.75 would solve this mess.

[Rowan]

Well, the symlink should be /usr/local/lib/libfmod.so -> libfmod<something>.so

Yup, I think it is:

$ cd /usr/local/lib
$ ls -l | grep fmod
lrwxrwxrwx 1 root root 26 Jan 4 20:28 libfmod.so -> /usr/lib/libfmod-3.74.1.so

But running scons still failed in the same way.

Maybe a 'strings /etc/ld.so.cache|grep fmod' could help you see if libfmod is available.

...

$ strings /etc/ld.so.cache|grep fmod
libfmod.so
/usr/local/lib/libfmod.so
libfmod-3.74.1.so
/usr/lib/libfmod-3.74.1.so

So... that looks like fmod has been loaded, I would have thought? (But have no real idea).

Thanks for all the help thus far.

[xscript]

For what you said:

Checking for fmod >= 3.74... failed
Checking fmod version >= 3.74... no

$ ls -l | grep fmod
lrwxrwxrwx 1 root root 26 Jan 4 20:28 libfmod.so -> /usr/lib/libfmod-3.74.1.so

It seems that you have installed fmod version 3.74.1, while the configure checks for 3.74 (or greater). I think the problem might be on the version comparison that scons performs, as it seems to not consider 3.74.1 being a greater version number than 3.74.

As thePill already pointed, you could try changing the fmod_version = '3.74' statement on build_config.py with the version you have (in fact, now I remember that I did exactly this to make it compile with the fmod 3.75 that I downloaded).

Hope this *finally* helps ;)

[Rowan]

Heh, no, I can't get that to work with either the 3.74.1 or 3.75 version.

[queue]

I had the same problem and I solved it.
Scons logs its configuration steps in the file config.log. I examined it and saw, that scons uses pkg-config to check for the library version. When I used the pkg-config command in the shell (and appand the parameter --modversion to get the version), it told me about a missing ".pc file".
In /usr/local/lib/pkgconfig I found a log4cpp.pc and used this file as template for fmod.pc.
Last, I changed the line in build_config.py to exactly the version of fmod, I have.

The same procedure goes for graphviz, too. (version 2.2-6 from SuSE-CD)

If there is another way to get this pkg-config info files, I'm looking forward to read about, because I'm new to linux and these were my first library problems.

[Rowan]

Hmm. It turns out I don't have a log4cpp.pc file either, but scons manages log4cpp fine.

What did you end up putting in your fmod.pc?

[queue]

content of fmod.pc:

Code: Select all

prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: fmod
Description: FMOD Sound System
Version: 3.75
Libs: -L${libdir} -lfmod -lnsl 
Cflags: -I${includedir} -g -O2

[Rowan]

Aha! That worked, once I copied fmod.h into /usr/local/include/. But now it doesn't like graphviz, as I rather expected it wouldn't:

$ scons
scons: Reading SConscript files ...
Configuring for POSIX system...
Checking for pkg-config... ok
Checking for GiGiSDL >= 0.6.0... ok
Checking for log4cpp >= 0.3.4b... failed
Checking log4cpp version == 0.3.4b... yes
Checking for C++ header file log4cpp/Category.hh... yes
Checking for log4cpp::Category::getRoot() in C++ library log4cpp... yes
Checking for fmod >= 3.75... ok
Checking for C header file fmod.h... yes
Checking for FSOUND_GetVersion() in C library fmod-3.75... yes
Checking for graphviz >= 0.15.0... ok
Checking for C header file graphviz/dot.h... no
Checking for C header file dot.h... no

I've bodged together a graphviz.pc, and I've tried copying dot.h (from a graphviz source download) into places I thought would work, but, my incompetance continues...

[Rowan]

Oh, damn. I've just realised I've got 2.6 installed, but I think FO only likes 2.2, doesn't it? Aha.

[Wolverine]

Oh, damn. I've just realised I've got 2.6 installed, but I think FO only likes 2.2, doesn't it? Aha.

It does. Unfortunatelly. I have the same problem, Yoghurt changed CVS so scons goes a step further (because dot.h is not needed anymore), but it still says that it cannot find render.h. I have quite recent graphviz-2.7 snapshot, because I need it, so FO won't compile. I wonder if it's really that hard to move to newer version, but I understand that programmers have better things to do than keeping in sync with newest versions of dependency libs. So I guess it'd be few months before I can compile CVS again. Too bad.

However I think it should be possible to compile graphviz-2.2 (if it's still around) to custom path and force scons to use this path. But unfortunatelly I don't have time to play with this.

[Tinyn]

Stupid question: I noticed there is only a x86 version of Fmod 3.xx for Linux; no AMD64 version. Does that mean FreeOrion will not compile under AMD 64 Linux?