From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9921 invoked by alias); 21 May 2013 10:50:18 -0000 Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org Received: (qmail 9912 invoked by uid 89); 21 May 2013 10:50:18 -0000 X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 21 May 2013 10:49:48 +0000 Received: from dslb-088-073-115-182.pools.arcor-ip.net ([88.73.115.182] helo=[192.168.42.222]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1Uek8W-0007SQ-HD; Tue, 21 May 2013 10:49:44 +0000 Message-ID: <519B5144.2010303@ubuntu.com> Date: Tue, 21 May 2013 10:50:00 -0000 From: Matthias Klose User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andrew Haley CC: GCJ-patches Subject: Re: [patch] include the %I spec when building the object file for the main function References: <519B20D6.5070806@ubuntu.com> <519B2FA7.1090404@redhat.com> In-Reply-To: <519B2FA7.1090404@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-q2/txt/msg00048.txt.bz2 Am 21.05.2013 10:26, schrieb Andrew Haley: > On 05/21/2013 08:23 AM, Matthias Klose wrote: >> The inclusion of stdc-predef.h is new in 4.8, the bits/predefs.h is not found in >> my case, because this header is on an include path, which is only added when cc1 >> is passed the -imultiarch option. The solution for me is to add the %I >> spec, when calling cc1 to build the main function. >> >> Ok for the trunk, and for 4.8 after the 4.8.1 release? > > This is slighty baffling. GCC is auto-including stdc-predef.h, but the > path info isn't sufficient? "because this header is on an include path, which is only added when cc1 is passed the -imultiarch option." sorry, but I don't know what to add else here to explai the issue. > And why does this affect gcj? "when calling cc1 to build the main function". So it does have it's own invocation of cc1, and doesn't use any specs how to call cc1, which is used for other C files. Matthias