From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060119 Fedora/1.5-1 Firefox/1.5 Description of problem: After upgrading to openal-0.0.8-2.fc4, torcs fails to find the symbol alutLoadWAVFile. When starting a new race, torcs now exits with a symbol lookup error. Version-Release number of selected component (if applicable): torcs-1.2.4-1.fc4 How reproducible: Always Steps to Reproduce: 1. Start torcs. 2. Verify openal is selected as the sound system. 3. Start a new race. Actual Results: ssggraph.so: undefined symbol: alutLoadWAVFile Expected Results: The race should have started. Additional info: It would appear that alut is no longer present in the openal package. The required symbol 'alutLoadWAVFile' is satisfied by freealut-1.0.0 (not currently in the extras repository). The freealut sources can be found at: www.openal.com/openal_webstf/downloads/freealut-1.0.0.tar.gz Visual Properties Report ------------------------ z-buffer depth: 24 (good) multisampling : available alpha bits : available OpenAL backend info: Vendor: OpenAL Community Renderer: Software Version: 1.1 Available sources: 1024 or more Available buffers: 1024 or more /usr/lib/torcs/torcs-bin: symbol lookup error: /usr/lib/torcs/modules/graphic/ssggraph.so: undefined symbol: alutLoadWAVFile
Created attachment 123977 [details] This patch adds an alut dependency to ssggraph.so. The attached patch should be applied after installing freealut. This patch will add an alut dependency to ssggraph.so.
After these modifications, torcs seems to work properly.
OK, so basically it's all about getting freealut into Extras, then :-) Are you willing to do that, or should I do it?
Created attachment 123981 [details] modified freealut spec file (In reply to comment #3) > OK, so basically it's all about getting freealut into Extras, then :-) > Are you willing to do that, or should I do it? I would appreciate it if you would place freealut into Extras. Attached is the modified freealut spec file that I used on my system.
Created attachment 124410 [details] This patch (for openal-0.0.8-2) removes '@requirements@' from openal.pc. The modified Torcs builds and runs properly with freealut-1.0.0-2.fc4 in Extras. Both Torcs and freealut-1.0.0-2 build properly with the patched openal-0.0.8-2. Once compiled, the modified Torcs runs fine with openal-0.0.8-2.fc4, with the patched openal-0.0.8-2, and with openal-0.0.9-0.2.20060204cvs.fc4. Unfortunately, Torcs fails to build with openal-0.0.9-0.2.20060204cvs.fc4. Configure fails to find alEnable in -lopenal. Outputs for "nm -D /usr/lib/libopenal.so.0.0.0 | grep alEnable": 1) for openal-0.0.9-0.2.20060204cvs.fc4: 00c57830 T alEnable 2) for openal-0.0.8-2.fc4: 00018390 T alEnable 3) patched openal-0.0.8-2: 00019120 T alEnable
I got here through bug 181989 Hmm, so alEnable is still there in openal-0.0.9-0.2.20060204cvs.fc4 but configure fails to find it. So although the newer openal release happens to fix this, this can also be fixed by fixing / patching ./configure for torcs, right? I'm asking because I believe that is a better idea as imho the new openal release with .so bump and probably abi instability to come is a bad idea. In the worst case scenario you could just circumvent the entire check in the configure script, right?
Created attachment 125329 [details] removes alEnable test from configure and configure.in Although the AC_CHECK_LIB test for alEnable should work, it does not. I have been unable to determine exactly why it fails. It seems to have something to do with changes in the libopenal.so internal symbol structure in openal-0.0.9-0.2.20060204cvs.fc4. Torcs compiles and runs properly with the attached patch and patch 123977. (In reply to comment #6) Thanks for suggesting circumventing the check. I concur that using the openal 20060226cvs version is not a good idea. The changelog entries show that some significant changes are in progress. The audio aliasing/distortion introduced in 20060226cvs is also a bit annoying (might be related to the source-rolloff-factor change).
Torcs compiles and runs properly with openal-0.0.9-0.4.20060204cvs.fc4 and the two patches (attachment 123977 [details] and attachment 125329 [details]).
Thanks a lot for the testing, patching, suggesting... etc. I'll take care of including those two patches in torcs today.
Torcs compiles and runs properly with openal-0.0.9-0.4.20060204cvs.fc4 and the patch attachment 123977 [details] . The patch attachement 125329 apparently also removes libopenal.so.0 from the torcs dynamic library list (oops). I discovered this after I made some system changes (odd segmentation faults suddenly appeared in torcs). Needless to say, this patch (attachment 125329 [details]) should not be applied.
This is taking me longer than expected, as I've also (and mostly) being testing the build on FC5, and got stuck for a looooooong while before I realized that the X libraries and includes weren't being detected properly, and that it was causing the configure check for libm to fail! Anyway, expect the FC5 (development) build very soon, then a backport to FC4 after some testing.
The backport works properly. Thanks.