From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23172 invoked by alias); 21 Jan 2014 23:40:57 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 23160 invoked by uid 89); 21 Jan 2014 23:40:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Jan 2014 23:40:56 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0LNerGD023814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jan 2014 18:40:53 -0500 Received: from [10.3.113.100] (ovpn-113-100.phx2.redhat.com [10.3.113.100]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s0LNep6f008872; Tue, 21 Jan 2014 18:40:52 -0500 Message-ID: <1390347651.10659.12.camel@deneb.redhat.com> Subject: Re: [PATCH] am33: bring port up to date with NPTL support From: Mark Salter To: "Joseph S. Myers" Cc: libc-ports@sourceware.org Date: Tue, 21 Jan 2014 23:40:00 -0000 In-Reply-To: References: <1340030785-32581-1-git-send-email-msalter@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00046.txt.bz2 On Tue, 2014-01-21 at 22:53 +0000, Joseph S. Myers wrote: > Any news on updating this patch for my review comments posted in June > 2012, and for all the subsequent relevant global changes in glibc for > which the port wasn't updated (or for which new files in the patch need > updating), with a view to getting it checked in so a further review of how > current the port is regarding global changes can be made on the basis of a > substantially working checked-in port? I really don't think it makes > sense just to leave the port around in such a bit-rotten state; either it > should be fixed, or it should be removed from glibc (with of course the > potential to add a port to this architecture again in future if one is > posted that is up-to-date with current glibc). > Sorry about letting this linger. At this point, I think removing it is the thing to do. The tls bits never got to upstream gcc and I ran into issues with the toolchain I couldn't get past.