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

[Manuel Novoa III]

On Sat, Sep 03, 2005 at 11:22:40AM +0200, Peter S. Mazinger wrote:
> 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?

I don't see the problem.  If you build libc without thread support and
you add libpthread from a thread-enabled build, then things will NOT
work.  There will be no locking done in libc itself.  So stdio and
several other subsystems will not be threasafe.  So it is good that you
get missing symbols.  That prevents you from trying to use a
non-thread-enabled libc with libpthread.

> > 
> > > 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*) ?

Just looked to refresh my memory.  No... several functions can be
replaced by inline code when thread support is turned off.  A (possibly
incomplete) list would be {f}getc, {f}putc, getchar, putchar, clearerr,
ferror, and feof.  There's currently no way to turn all these off.  But
a config option could be added easily enough.

> > > 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)?

As I said, simply changing libc/stdio/Makefile and enabling these to
build for the non-thread case should be all you have to do.  I'm fine
with having these available for the non-thread version.

Manuel