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 132

Summary: stop using deprecated mutex funcs with newer glibc versions
Product: SDL Reporter: Mike Frysinger <vapier>
Component: threadAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: HG 1.2   
Hardware: x86   
OS: Linux   
Attachments: libsdl-older-mutex-funcs.patch

Description Mike Frysinger 2006-02-01 20:22:04 UTC
older versions of glibc used pthread_mutexattr_setkind_np() while nowadays it's deprecated in favor of pthread_mutexattr_settype() ... atm, SDL_sysmutex.c always uses the deprecated one on linux systems

patch attached will enable use of the newer func for glibc-2.3.x+ ... or i could write up a configure test to see if libpthread supports pthread_mutexattr_settype() and use that ... doesnt matter to me ;)
Comment 1 Mike Frysinger 2006-02-01 20:23:28 UTC
Created attachment 64 [details]
libsdl-older-mutex-funcs.patch
Comment 2 Sam Lantinga 2006-02-03 00:52:36 UTC
(In reply to comment #0)
> older versions of glibc used pthread_mutexattr_setkind_np() while nowadays it's
> deprecated in favor of pthread_mutexattr_settype() ... atm, SDL_sysmutex.c
> always uses the deprecated one on linux systems
> 
> patch attached will enable use of the newer func for glibc-2.3.x+

I have glibc-2.3.5, and PTHREAD_MUTEX_RECURSIVE is only defined if __USE_UNIX98 is defined, which it isn't by default.

However, it's not a bad idea to use it when available, so I'm writing a configure test to do the right thing.  Thanks!
Comment 3 Sam Lantinga 2006-02-03 01:31:11 UTC
(In reply to comment #2)
> I have glibc-2.3.5, and PTHREAD_MUTEX_RECURSIVE is only defined if __USE_UNIX98
> is defined, which it isn't by default.

You have to define _GNU_SOURCE to get the __USE_UNIX98 API calls.
I'm setting this up in configure.in, thanks!