MIPS NPTL patches

[Dan E]

On Thu, 09 Apr 2009 00:48 -0700, "Khem Raj" <raj.khem at gmail.com> wrote:
> On Wednesday 08 April 2009 10:27:44 pm Dan E wrote:
> > OK, I lied.  There are 4 patches in all for this set.
> > 
> > I could not get a clean build without these changes. 
> 
> what error messages do you get without this patch ?
> 
> > A better way would be nice.
> > No other arch needs these to build the NPTL branch, do they?  MIPS shouldn't
> > either, but I don't know how to do it gracefully.  Tips, flames, etc. all
> > welcome and encouraged.
> > 
> > ---------- start patch ----------
> > Index: uClibc-nptl/libc/inet/getproto.c
> > ===================================================================
> > --- uClibc-nptl/libc/inet/getproto.c	(revision 26031)
> > +++ uClibc-nptl/libc/inet/getproto.c	(working copy)
> > @@ -71,6 +71,10 @@
> >  /* libc_hidden_proto(fclose) */
> >  /* libc_hidden_proto(abort) */
> >  
> > +#ifdef __UCLIBC_HAS_THREADS_NATIVE__
> > +#include <pthreadP.h>
> > +#endif
> > +
> >  #include <bits/uClibc_mutex.h>
> >  __UCLIBC_MUTEX_STATIC(mylock, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP);
> 
> <snip>
> 
> > ---------- end patch ------------
> > 
> 
> -- 
> Khem Raj

Good catch, Khem.  Apparently none.  I had been getting a lot of errors
about missing 'pthread_cleanup_push' and/or 'pthread_cleanup_pop'. 
Since those are actually macros, I kept adding the includes for
'pthreadP.h' until they all went away.  That was on Rob Landley's FWL
build environment for qemu testing.  When it was working I moved the
patches back over to my real build environment for my MIPS target and
it's been sitting there for over a week now while I debugged an
unrelated problem.

I removed that patch from the build tree and everything was still OK.  I
went back to the FWL environment and removed the patch from there, too. 
Everything built OK.  I don't know what changed in the meantime.  I know
I didn't imagine the problems I had.  Operator error.

Please disregard the patch that adds "#include <pthreadP.h>" to many
libc files.

I don't understand why that problem just went away.  I'm happy that it
did, of course.  It didn't seem like something that should be needed,
especially when you consider that none of the other arches needed those
changes to the libc code.

Thank you for spotting that.

DanE

-- 
http://www.fastmail.fm - IMAP accessible web-mail