Date: Fri, 20 Mar 2009 10:40:40 -0700 From: Sam Leffler <sam@freebsd.org> To: Coleman Kane <cokane@freebsd.org> Cc: svn-src-head@freebsd.org, Vasil Dimov <vd@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r189828 - in head: include sys/sys Message-ID: <49C3D518.6070105@freebsd.org> In-Reply-To: <1237567495.1993.2.camel@localhost> References: <200903142010.n2EKAESF006945@svn.freebsd.org> <20090320140015.GA17645@hub.freebsd.org> <20090320153405.GA62675@zim.MIT.EDU> <49C3BCD4.4030605@freebsd.org> <1237567495.1993.2.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49C3D518.6070105>