|Summary:||Torcs crashes with ssggraph.so: undefined symbol: alutLoadWAVFile|
|Product:||[Fedora] Fedora||Reporter:||Philip Heuer <pheuer>|
|Component:||torcs||Assignee:||Matthias Saou <matthias>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-04-07 13:41:37 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Philip Heuer 2006-02-01 17:25:23 UTC
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
Comment 1 Philip Heuer 2006-02-01 17:34:25 UTC
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.
Comment 2 Philip Heuer 2006-02-01 17:41:15 UTC
After these modifications, torcs seems to work properly.
Comment 3 Matthias Saou 2006-02-01 17:44:40 UTC
OK, so basically it's all about getting freealut into Extras, then :-) Are you willing to do that, or should I do it?
Comment 4 Philip Heuer 2006-02-01 17:56:20 UTC
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.
Comment 5 Philip Heuer 2006-02-08 21:29:06 UTC
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
Comment 6 Hans de Goede 2006-02-26 21:19:16 UTC
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?
Comment 7 Philip Heuer 2006-02-27 16:47:37 UTC
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).
Comment 8 Philip Heuer 2006-03-01 03:04:00 UTC
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]).
Comment 9 Matthias Saou 2006-03-01 10:05:00 UTC
Thanks a lot for the testing, patching, suggesting... etc. I'll take care of including those two patches in torcs today.
Comment 10 Philip Heuer 2006-03-10 03:33:20 UTC
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.
Comment 11 Matthias Saou 2006-03-10 15:33:25 UTC
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.
Comment 12 Philip Heuer 2006-03-24 17:59:11 UTC
The backport works properly. Thanks.