From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68198 invoked by alias); 7 Feb 2017 16:58:42 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 68165 invoked by uid 89); 7 Feb 2017 16:58:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.0 required=5.0 tests=BAYES_20,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=cpp, 1.9.1, isystem, Hx-languages-length:1712 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Feb 2017 16:58:31 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 556AC707; Tue, 7 Feb 2017 08:58:29 -0800 (PST) Received: from [10.2.206.52] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 07B9C3F458 for ; Tue, 7 Feb 2017 08:58:28 -0800 (PST) To: newlib@sourceware.org From: Thomas Preudhomme Subject: [PATCH, newlib/ARM] Fix cpp invocation for C++ in nano spec Message-ID: <9a09dd05-1a47-bb27-b47b-3ea8d03f3a35@foss.arm.com> Date: Tue, 07 Feb 2017 16:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------40E1C72B69FC6AAA7A533C1F" X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00134.txt.bz2 This is a multi-part message in MIME format. --------------40E1C72B69FC6AAA7A533C1F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 525 Hi, The changes in c028685518a261f6d0dab0d7ed15f9570ab9b3d0 to use newlib-nano's include directory work for cc1 but not cc1plus. cc1plus comes with its own cpp spec which does not have a name attached to it. This patch uses the renaming trick on cpp_options instead of cpp, as cpp_options is used both by cc1 and cc1plus. Tested with a small C program including string.h. Preprocess annotations show that both when using -x c and -x c++ newlib'nano's newlib.h gets chosen. Is this ok for master? Best regards, Thomas --------------40E1C72B69FC6AAA7A533C1F Content-Type: text/x-patch; name="fix_nano_spec_cpp_invocation.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fix_nano_spec_cpp_invocation.patch" Content-length: 1169 >From ae65c363338e95148e222dc88c31d12ad4749c3b Mon Sep 17 00:00:00 2001 From: Thomas Preud'homme Date: Mon, 6 Feb 2017 15:51:02 +0000 Subject: [PATCH] [PATCH, newlib/ARM] Fix cpp invocation for C++ in nano spec Hi, The changes in c028685518a261f6d0dab0d7ed15f9570ab9b3d0 to use newlib-nano's include directory work for cc1 but not cc1plus. cc1plus comes with its own cpp spec which does not have a name attached to it. This patch uses the renaming trick on cpp_options instead of cpp, as cpp_options is used both by cc1 and cc1plus. --- libgloss/arm/elf-nano.specs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libgloss/arm/elf-nano.specs b/libgloss/arm/elf-nano.specs index 575f47d..324107e 100644 --- a/libgloss/arm/elf-nano.specs +++ b/libgloss/arm/elf-nano.specs @@ -1,9 +1,9 @@ %rename link nano_link %rename link_gcc_c_sequence nano_link_gcc_c_sequence -%rename cpp nano_cpp +%rename cpp_options nano_cpp_options -*cpp: --isystem =/include/newlib-nano %(nano_cpp) +*cpp_options: +-isystem =/include/newlib-nano %(nano_cpp_options) *nano_libc: -lc_nano -- 1.9.1 --------------40E1C72B69FC6AAA7A533C1F--