trying to find a (compat) way to move to nptl (when ready)

Peter S. Mazinger ps.m at gmx.net
Sat Sep 3 09:22:40 UTC 2005


On Fri, 2 Sep 2005, Manuel Novoa III wrote:

> Hello Peter,
> 
> On Fri, Sep 02, 2005 at 06:34:00PM +0200, Peter S. Mazinger wrote:
> > Hello!
> > 
> > I am trying to remove libpthread dependency from a dev box, so that if 
> > nptl is done, we can move "smoothly" to it, looking for an update path.
> > Attached is a patch that corrects the case if UCLIBC_HAS_THREADS is not 
> > enabled (removing related headers on install)
> > at least 4 functions are calling for trouble (missing from the non-thread 
> > version of uClibc)
> > _stdio_user_locking
> 
> This is for internal use by libc and libpthread only.
> 
> > __rpc_thread_destroy
> 
> Ditto...  Anything using either of the above deserves to break.

Following happened:
I have rebuilt uclibc without THREADS, but left the pthread lib 
(only libpthread.so.0) in place until I rebuild all the apps using it. 
Gentoo's build system uses python and was built against libpthread and 
that needed these 2. Now the problem was that libc was built w/o threads 
(not providing these 2 functions), but the pthread lib was present. Could 
maybe these 2 (and others if necessary) be moved completely to the pthread 
lib (or some weak version, if not found in libc), so that libc can be 
replaced w/o problem?

> 
> > flockfile
> > funlockfile
> 
> You should be able to enable both of the above plus ftrylockfile for the
> non-thread build to produce stub versions in libc.
> 
> > I have overcome this by adding dummies to a shared lib that was preloaded 
> > until the apps were rebuilt, that needed these.
> 
> You'll also want to disable getc/putc macro support.

Only exactly getc/putc or all related ones (*getc*/*putc*) ?

> 
> > Does anyone have an idea how this could be integrated into uClibc, so that 
> > an update path could be provided?
> > 
> > Thanks, Peter
> 
> Just remove the UCLIBC_HAS_THREADS test in libc/stdio/Makefile to enable
> flockfile and friends.  The other symbols should never be referenced by
> apps or other libs.

The patch I have attached earlier ifdefs these 3 in stdio.h. Should I 
rather create stubs for these 3 for non-thread version and leave the 
header unchanged? Should this rather be a separate compatibility option 
(if at all acceptable upstream)?

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list