Bug 179614

Summary: Torcs crashes with ssggraph.so: undefined symbol: alutLoadWAVFile
Product: [Fedora] Fedora Reporter: Philip Heuer <pheuer>
Component: torcsAssignee: Matthias Saou <matthias>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: extras-qa, hdegoede
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-07 13:41:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
This patch adds an alut dependency to ssggraph.so.
modified freealut spec file
This patch (for openal-0.0.8-2) removes '@requirements@' from openal.pc.
removes alEnable test from configure and configure.in none

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):

How reproducible:

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:


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

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

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.