From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7213 invoked by alias); 29 Aug 2013 12:22:16 -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 7201 invoked by uid 89); 29 Aug 2013 12:22:15 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Aug 2013 12:22:15 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VF1Eo-0006RT-AL from joseph_myers@mentor.com ; Thu, 29 Aug 2013 05:22:10 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Aug 2013 05:22:10 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Thu, 29 Aug 2013 13:22:08 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VF1El-0000g0-JZ; Thu, 29 Aug 2013 12:22:07 +0000 Date: Thu, 29 Aug 2013 12:22:00 -0000 From: "Joseph S. Myers" To: Roland McGrath CC: Subject: Re: [PATCH roland/arm-mcount] ARM: Disable compat mcount code when unneeded. In-Reply-To: <20130827173014.D264D2C097@topped-with-meat.com> Message-ID: References: <20130827173014.D264D2C097@topped-with-meat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-08/txt/msg00060.txt.bz2 On Tue, 27 Aug 2013, Roland McGrath wrote: > The obsolete _mcount entry point is not needed in a shared library not > supporting any old ABIs. This change also makes it unavailable for static > linking altogether. We have never supported linking old object files with > new libraries, so that should not be a problem for existing configurations. Isn't this about objects built with old compilers (before GCC 4.4, when __gnu_mcount_nc was introduced; arm*-*-linux-gnueabi support was added in 4.1), which is generally supported, rather than objects built with old library headers, which isn't? -- Joseph S. Myers joseph@codesourcery.com