From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11]) by mail.openembedded.org (Postfix) with ESMTP id 3200B719A4 for ; Fri, 1 Dec 2017 01:46:30 +0000 (UTC) Received: from ALA-HCB.corp.ad.wrs.com (ala-hcb.corp.ad.wrs.com [147.11.189.41]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id vB11kVHY002049 (version=TLSv1 cipher=AES128-SHA bits=128 verify=OK); Thu, 30 Nov 2017 17:46:32 -0800 Received: from localhost.corp.ad.wrs.com (128.224.162.229) by ALA-HCB.corp.ad.wrs.com (147.11.189.41) with Microsoft SMTP Server id 14.3.361.1; Thu, 30 Nov 2017 17:46:19 -0800 To: Alexander Kanavin , References: From: Robert Yang Message-ID: <8d0f0ec4-82a6-c63e-2fac-e012e9ee2ec5@windriver.com> Date: Fri, 1 Dec 2017 09:46:00 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Subject: Re: [PATCH 4/5] webkitgtk: fix compile error when len(TMPDIR) == 410 X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 01:46:31 -0000 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Hi Alexander, On 11/30/2017 07:34 PM, Alexander Kanavin wrote: > On 11/30/2017 03:45 AM, Robert Yang wrote: >> One of the gcc command line was too long (longer than 160,000 characters) when >> len(TMPDIR) == 410, so there was an "Argument list too long" error: >> $ bitbake webkitgtk >> i586-poky-linux-g++: error trying to exec [snip] execv: Argument list too long >> >> The cmake doesn't support relative path, so we have to edit flags.make to fix >> the problem: >> - Replace -I${RECIPE_SYSROOT} with -I= >> - Replace "-I${S}/path1/in/S -I ${S}/path2/in/S" with >>    "-iprefix ${S} -iwithprefixbefore /path1/in/S -iwithprefixbefore /path2/in/S" > > Where does flags.make come from? Can you fix the problem at the source, rather > than patch the file with a custom, unwieldy function after the fact? The flags.make is generated by cmake, and as I said in the commit message: "The cmake doesn't support relative path, so we have to edit flags.make to fix the problem" I'm not familiar with cmake, please let me know if there is a way to make it generate a relative path in flags.make. // Robert > > Alex >