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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
