svn commit: r189828 - in head: include sys/sys

Coleman Kane cokane at FreeBSD.org
Fri Mar 20 09:46:30 PDT 2009


On Fri, 2009-03-20 at 08:57 -0700, Sam Leffler wrote:
> David Schultz wrote:
> > On Fri, Mar 20, 2009, Vasil Dimov wrote:
> >   
> >> On Sat, Mar 14, 2009 at 08:10:14PM +0000, David Schultz wrote:
> >>     
> >>> Author: das
> >>> Date: Sat Mar 14 20:10:14 2009
> >>> New Revision: 189828
> >>> URL: http://svn.freebsd.org/changeset/base/189828
> >>>
> >>> Log:
> >>>   Fix the visibility of several prototypes. Also move pthread_kill() and
> >>>   pthread_sigmask() to signal.h. In principle, this shouldn't break anything,
> >>>       
> >> [...]
> >>
> >> But it did break, see http://www.freebsd.org/cgi/query-pr.cgi?pr=132828
> >>
> >> I think one's namespace shouldn't be polluted with the prototype of
> >> pthread_kill() if he has not included pthread.h.
> >>     
> >
> > The pthreads API has always defined pthread_kill() to be in
> > signal.h, not pthread.h. This is what is done in glibc and
> > elsewhere.
> >
> > GNU Pth has some bogus and extremely unportable hacks to ``trick''
> > system headers into not declaring symbols:
> >
> >   /*
> >    * Prevent system includes from implicitly including
> >    * possibly existing vendor Pthread headers
> >    */
> >   #define PTHREAD
> >   #define PTHREAD_H
> >   #define _PTHREAD_T
> >   #define _PTHREAD_H
> >   #define _PTHREAD_H_
> >   #define PTHREAD_INCLUDED
> >   #define _PTHREAD_INCLUDED
> >   #define SYS_PTHREAD_H
> >   #define _SYS_PTHREAD_H
> >   #define _SYS_PTHREAD_H_
> >   #define SYS_PTHREAD_INCLUDED
> >   #define _SYS_PTHREAD_INCLUDED
> >   #define BITS_PTHREADTYPES_H
> >   #define _BITS_PTHREADTYPES_H
> >   #define _BITS_PTHREADTYPES_H_
> >   #define _BITS_SIGTHREAD_H
> >
> > The one that works for glibc is _BITS_SIGTHREAD_H. I'd rather not
> > be complicit in these shenanigans, but if we can't easily fix the
> > problem in Pth, I suppose we can teach signal.h about one of these
> > bogus macros. What do you think?
> >
> >   
> 
> Dumb question, why do we need devel/pth?  Isn't the native pthread 
> support sufficient?
> 
>     Sam
> 

For whatever reason, both security/libassuan and security/gnupg want
pth.

I was able to solve the problem by removing the "#include <signal.h>"
from the offending file (there is only one) in devel/pth. After that, it
built fine and I am using it now.

Maybe devel/pth doesn't even really need to #include <signal.h>
anymore....

-- 
Coleman Kane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20090320/8e2b7fbe/attachment.pgp


More information about the svn-src-head mailing list