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

[Coleman Kane]

On Fri, 2009-03-20 at 10:40 -0700, Sam Leffler wrote:
> 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
> 

I've found that many of the GNU apps are notorious for this. I really
can't say that I know why libassuan or gnupg explicitly require GNU pth,
rather than first attempting to use POSIX pthread API. Their configure
scripts both want to search for and run pth-config, and fail to enable
some sort of threaded features if it doesn't exist. I already tried
removing pth stuff from both port Makefiles to see what would happen. I
didn't spend much time on it after I figured out that devel/pth would
just work if I removed the signal.h include.

I am guessing that some non-standard extensions which GNU pth provides
are not provided by the normal POSIX spec.

In fact, libassuan just goes ahead and uses a bunch of pth_* overrides
for dealing with them in a thread-safe manner (waitpid, read, write,
select, usleep).

According to GnuPG (security/gnupg in the configure.ac file):
*** To support concurrent access to the gpg-agent and the SCdaemon
*** we need the support of the GNU Portable Threads Library.
*** Download it from ftp://ftp.gnu.org/gnu/pth/
*** On a Debian GNU/Linux system you might want to try
***   apt-get install libpth-dev

-- 
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/1c0edcdc/attachment.pgp