Bug 727 - On uClibc configured with thread, including <stdio.h> leads to <pthread.h>/<sched.h> inclusion
Summary: On uClibc configured with thread, including <stdio.h> leads to <pthread.h>/<s...
Status: NEW
Alias: None
Product: uClibc
Classification: Unclassified
Component: Standard Compliance (show other bugs)
Version: 0.9.30.1
Hardware: PC Linux
: P5 enhancement
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-18 11:47 UTC by Yann Droneaud
Modified: 2009-11-22 00:46 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yann Droneaud 2009-11-18 11:47:24 UTC
When thread support is enabled in uClibc, stdio uses mutex to protect access to stream.

To do it, uClibc uses pthread mutex through macros defined in <bits/uClibc_stdio.h>.

<stdio.h> includes <bits/uClibc_stdio.h>, which includes <bits/uClibc_mutex.h>, then <pthread.h> and <sched.h> and finally <bits/sched.h>.

uClibc should not export <pthread.h> and <sched.h> as part of internals.
Symbols needed for locked stdio implementation should be private to uClibc, not the standards one.

This is namespace pollution.

See The Open Group Base Specifications Issue 7,  2. General Information,  2.2 The Compilation Environment, 2.2.2 The Name Space 
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02

This is especially a problem since "clone()" prototype is exported and conflicts with some code that don't expect it to be defined. "clone()" is a Linux extension.

Regards.
Comment 1 Yann Droneaud 2009-11-18 11:48:13 UTC
See http://bugs.gentoo.org/show_bug.cgi?id=197013
Comment 2 Mike Frysinger 2009-11-22 00:46:46 UTC
also breaks screen as noted long ago in:
http://bugs.gentoo.org/show_bug.cgi?id=168281

i looked at fixing this a few times, but the reliance of pthread structs by pushing the locking into the API made this hard to do.  didnt get anything usable.