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

Sam Leffler sam at freebsd.org
Fri Mar 20 10:40:42 PDT 2009


Coleman Kane wrote:
> 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....
>   

Well a recent foray into dealing with this ports breakage made me 
question why we drag in various packages.  devel/pth is one example; I 
see many others scroll by that appear to duplicate functionality in the 
base system.  At the end of the day it's clearly an issue of maintenance 
overhead--we'd have to mod apps to do things like remove use of 
gnu-long-opts in to switch away from things like gtar and the savings is 
unclear.  But I can ask...

    Sam



More information about the svn-src-head mailing list