From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7603 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Missing functions for linux perf Date: Fri, 8 May 2015 15:49:13 -0400 Message-ID: <20150508194913.GD17573@brightrain.aerifal.cx> References: <554D119A.2090709@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1431114568 31273 80.91.229.3 (8 May 2015 19:49:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 May 2015 19:49:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7616-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 08 21:49:27 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YqoH1-0000Dc-Bz for gllmg-musl@m.gmane.org; Fri, 08 May 2015 21:49:27 +0200 Original-Received: (qmail 28037 invoked by uid 550); 8 May 2015 19:49:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28014 invoked from network); 8 May 2015 19:49:25 -0000 Content-Disposition: inline In-Reply-To: <554D119A.2090709@skarnet.org> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7603 Archived-At: On Fri, May 08, 2015 at 09:42:18PM +0200, Laurent Bercot wrote: > > Hi, > I'm trying to compile Linux's "perf" tool with musl. Barring > a few truckloads of warnings regarding redefined symbols in > kernel headers, I managed to get the core source files compiled, > but there are errors at link time - the following functions are > undefined: > > pthread_attr_setaffinity_np > sched_getcpu > > Sure, those are glibc extensions, but would it be possible to > have them in musl, or is there a good reason not to ? For pthread_attr_setaffinity_np, I'd rather not since it requires having allocated state in pthread_attr_t objects, which requires auditing any place they're copied by value, and other headaches. The same thing can be achieved by pthread_setattr_np after the thread starts, so putting the affinity in the attr object just seems gratuitously hideous. I have no fundamental objection to sched_getcpu. Rich