From owner-svn-src-head@FreeBSD.ORG Sat Apr 11 19:30:37 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEF9C106567C for ; Sat, 11 Apr 2009 19:30:37 +0000 (UTC) (envelope-from cokane@cokane.org) Received: from mail-out2.fuse.net (mail-out2.fuse.net [216.68.8.171]) by mx1.freebsd.org (Postfix) with ESMTP id A180B8FC22 for ; Sat, 11 Apr 2009 19:30:37 +0000 (UTC) (envelope-from cokane@cokane.org) X-CNFS-Analysis: v=1.0 c=1 a=g2CHTHa2IaQA:10 a=6I5d2MoRAAAA:8 a=GSfbVeVPvHpJqZVy4VcA:9 a=8CPma2sQlQqFpa87IRsA:7 a=5ZlNOZUpwx5GaYLShau2ROsknWEA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: gwout2 smtp.mail=cokane@cokane.org; spf=neutral Received-SPF: neutral (gwout2: 74.215.227.9 is neither permitted nor denied by domain of cokane.org) Received: from [74.215.227.9] ([74.215.227.9:50655] helo=mail.cokane.org) by gwout2 (envelope-from ) (ecelerity 2.2.2.37 r(28805/28810M)) with ESMTP id 33/21-25989-A3CE0E94; Sat, 11 Apr 2009 15:15:06 -0400 Received: from [10.128.128.2] (unknown [10.128.128.2]) by mail.cokane.org (Postfix) with ESMTPSA id A6A8C1143C; Sat, 11 Apr 2009 16:20:31 -0400 (EDT) From: Coleman Kane To: Stanislav Sedov In-Reply-To: <20090411214410.c53d0fb1.stas@FreeBSD.org> References: <200904111657.n3BGvpsC092703@svn.freebsd.org> <20090411210702.ce5325b9.stas@FreeBSD.org> <20090412021841.673a200b.nork@FreeBSD.org> <20090411214410.c53d0fb1.stas@FreeBSD.org> Content-Type: text/plain Date: Sat, 11 Apr 2009 15:13:15 -0400 Message-Id: <1239477195.2952.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, Norikatsu Shigemura , vd@FreeBSD.org, svn-src-head@FreeBSD.org, David Schultz Subject: Re: svn commit: r190943 - head/include X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:30:38 -0000 On Sat, 2009-04-11 at 21:44 +0400, Stanislav Sedov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, 12 Apr 2009 02:18:41 +0900 > Norikatsu Shigemura mentioned: > > > On Sat, 11 Apr 2009 21:07:02 +0400 > > Stanislav Sedov wrote: > > > > Log: > > > > GNU Pth has some fragile kludges that were broken by r189828. > > > > I've discussed this with the Pth maintainer and no clear solution > > > > has emerged on the ports side of things, so for now, hack around > > > > the issue in signal.h. > > > Can't we just put a patch in ports tree itself? What meant under 'no > > > clean solution emerged'? I can prepare a patch, if needed. > > > > I think so, too. I have a quick hack patch. > > > > ports/devel/pth/files/patch-pth_p.h.in > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > --- pth_p.h.in.orig 2006-06-09 02:54:03.000000000 +0900 > > +++ pth_p.h.in 2009-04-08 15:05:12.911807009 +0900 > > @@ -32,7 +32,7 @@ > > #include > > #include > > #include > > -#include > > +//#include > > #include > > #include > > #include > > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > Or just drop the line. Vasil, what do you think about the possibility to > commit this patch into the tree? I think we should have a workaround in ports > tree (it is one of the things what it was designed for) than in the src tree. > Better would be to implement a workaround upstream, though. I think something > like > #if !(defined(__FreeBSD__) && __FreeBSD_version >= %%PTHREAD_CHANGE_VERSION%%) > #include > #endif > where %%PTHREAD_CHANGE_VERSION%% would correspond to the __FreeBSD_version where > the change was introduced, could be safely submitted upstream. > > - -- > Stanislav Sedov > ST4096-RIPE I agree... if you've been discussing it with the Pth maintainer, then what are the chances that you can get Pth to change their behavior? Since Pth is supposed to be a support library that works on a large collection of platforms to provide a consistent multithreading and I/O API to users, I would imagine that their code should not #include when: a) They don't need it on our platform, and b) It breaks things on our platform. -- Coleman Kane