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