Compilation errors in audio in Linux

#1 Did you install openal and add openal's path to ldconfig conf file (can't remember its exact name but its in the new linux docs)

-Tim aka Spock

#2 I can't say I have. Does it comes with the SDK or do I have to get it myself?

#3 Ok, here's some of the errors:
In file included from platform/platformAL.h:21,
from platform/platformAudio.h:15,
from audio/audio.h:11,
from audio/audio.cc:7:
../lib/openal/LINUX/AL/alc_func.h:8: syntax error before '*'
../lib/openal/LINUX/AL/alc_func.h:9: 'alcCloseDevice' was not declared in this scope
../lib/openal/LINUX/AL/alc_func.h:9: 'ALCdevice' was not declared in this scope
../lib/openal/LINUX/AL/alc_func.h:9: 'device' was not declared in this scope
../lib/openal/LINUX/AL/alc_func.h:9: ISO C++ forbids declaration of 'ALCviod' with no type

That's the first few just from alc_func.h
Now for audio.cc:

audio/audio.cc:32: syntax error before '*'
audio/audio.cc:33: syntax error before '*'
audio/audio.cc: In function 'int loopingImageSort (const void *, const void *)':
audio/audio.cc:141: warning: return to 'int' from 'float'
audio/audio.cc:141:warning:argument to 'int' from 'float'
audio/audio.cc: In function 'void alxSourcePlay (unsigned int, Resource, const Audio::Description *, const MatrixF*)':
audio.cc:395:'AL_LOOPING' undeclared

Is this really because I don't have openAL from their web site?

#4 Ok, I downloaded, and installed OpenAL and ran ldconfig, but when i make, it still gives me the same errors.

I got OpenAL from here:
http://how.to/sblive/

#5 A couple things:

The header includes should be al/*, not AL/* . The headers are in torque\lib\openal\LINUX, and should not be included from anywhere else on the system.

The openal package available on this site is not required to compile the engine. It is only required for sound at run time.

When you copy a torque directory from a windows partition, the name of the torque\lib\openal\LINUX directory gets downcased to torque\lib\openal\linux. This will cause "no such file or directory" compilation errors, so you must upcase it again.

Please make sure that the headers you are including are from torque\lib\openal\LINUX and not somewhere else.

#6 actually, now that I got it straight from the GG cvs, it seems to work. I guess it's just the fault of the guy who hosted OUR cvs.

Yeah, now that I look at the directory structures, in our version, it's openal/LINUX/AL instead of openal/LINUX/al

#7 Alright, now it compiled/linked, I got my binary, but now it segmentation faults right after it's done loading a mission. Backtrace tells me that it's in interior/forceField.cc:471 in proccessTriFan ()

Is anybody else getting this error?

#8 Never seen that error before. What version of the code are you running, HEAD, Release_1_1_1, etc?

#9 It is whatever was up on the GG cvs about 10 minutes ago on the HEAD. Also, I'm not getting any sound even though I installed the latest version of OpenAL.

#10 Hmm, I'm going to have to noodle a bit on that crash problem. processTriFan is assembly code built with NASM; that might have something to do with it. Please give me this info: distribution, compiler version, kernel version, cpu type/speed, ram, and video card and driver version.

For the OpenAL problem, you might want to try this library if you're not using it already. Also check out the openal notes here.
After starting the game, you should be able to scroll up
in the console to see if OpenAL is getting loaded.

#11 Distro: RedHat 7.1 2.96-81
Compiler version: 2.96 20000731
Kernel: 2.4.2.2
CPU: P3-500mhz
RAM: 256
Video Card: PNY Verto (GeForce 2 Ti)
Driver version: Not sure, but it's the latest det drivers from nVidia

#12 Are you using your own mission/data files, or just the standard example stuff in the head?

#13 Hey John -

As another reminder, since the CW/PC IDE project doesn't use NASM, it would be possible to build the linux project with the C-version of process code. Just a thought -- might be helpful for debugging purposes...

d

#14 I've tried it using our build and straight from the GG cvs head. Same result.

Well, the openal thing my fault. I forgot to add the openal dir to my ld.so.conf file. After a quick ldconfig, it worked. But it still crashes right after it loads.

#15 Dave: yes it would be good to try that. Although in theory the assembly should work for linux if it works on the other platforms...

Chris: are you using your own missions/artwork, or the standard example stuff? Since the crash occurs in forceField.cc, that might be why I've never seen it...

#16 I'm using what is on the CVS head, so the standard example stuff.

#17 Hmm, I can't reproduce it on my end, but there is some weirdness here. For one thing line 471 of forceField.cc is the last line of the file. And forceField.cc doesn't even use processTriFan directly.

There's a suspicious line in itfdump.asm. On line 363 it pops ebp twice, after pushing it just once in the prologue. Thats seems bad. Please try commenting out that second pop, and rebuild to see if it works.

#18 I assume that to comment out something in asm that you stick a ; at the beginning of the line, and i did, but that didn't work. It still segmentation faults.

#19 There are a couple versions of processTriFan(). Is it crashing in the base processTriFan(), or one of the other functions?

You could try what Dave suggested and use the C version of itfdump. If you still get crashes then we're probably looking in the wrong place.

To do this, edit engine/targets.torque.mk, and on line 152 replace itfdump.asm with itfdump_c.cc. Then rebuild and try again...