We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 921

Summary: Name clashes in SDL_Mixer and SDL_Sound Timidity code
Product: SDL_mixer Reporter: Guido <guidoj>
Component: miscAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 1.2.11   
Hardware: All   
OS: All   

Description Guido 2010-01-03 07:38:32 UTC 
When both SDL_Mixer and SDL_Sound are built with the Timidity code enabled this will lead to name clashes in programs that use both libraries.

Example: because SDL_Mixer does not support MIDI samples (only MIDI music) my program uses SDL_Sound to convert MIDI samples to WAV format which are in turn played/mixed using SDL_Mixer. At first both SDL_Sound and SDL_Mixer were built with Timidity code enabled. This worked fine until the program was terminated and Mix_CloseAudio was called. Mix_CloseAudio would call Timidity_Close (through close_music) from within SDL_Mixer which in turn would call free_instruments from within SDL_Sound! Of course free_instruments from within SDL_Mixer should have been called, but the linker apparently got them mixed up.

On linux this would result in a segmentation fault, but I expect this to be independent of hardware and OS.

Because I don't need the MIDI support in SDL_Mixer I disabled it there, which fixed the problem for me. Of course this is only a temporary solution because it is not possible to install another program that does require Timidity enabled in SDL_Mixer at the same time.
Comment 1 Ryan C. Gordon 2010-01-04 09:08:35 UTC 
Both SDL_sound and SDL_mixer should probably take some effort to not export the Timidity symbols, which would solve the problem. I'll look into this.

--ryan.
Comment 2 Ryan C. Gordon 2010-01-05 12:07:14 UTC 
svn revision #5442 makes the Timidity symbols private in SDL_mixer, which means it _should_ find the right ones even if SDL_sound also exposes them.

SDL_sound's mercurial repository now has similar fixes, too.

--ryan.