From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933286AbcIWHFY (ORCPT ); Fri, 23 Sep 2016 03:05:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:49779 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753233AbcIWHFW (ORCPT ); Fri, 23 Sep 2016 03:05:22 -0400 Subject: Re: gen_initramfs_list.sh escaping problem or stale dependency file? To: Florian Fainelli References: <20160913072414.GA13667@sepie.suse.cz> <7db977f9-c9fa-4ae6-de75-834513a2d367@gmail.com> Cc: linux-kernel@vger.kernel.org, sam@ravnborg.org, mmarek@suse.cz, joe@perches.com, lede-dev@lists.infradead.org, openwrt-devel@lists.openwrt.org From: Michal Marek Message-ID: Date: Fri, 23 Sep 2016 09:05:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <7db977f9-c9fa-4ae6-de75-834513a2d367@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-09-19 22:00, Florian Fainelli wrote: > On 09/13/2016 12:24 AM, Michal Marek wrote: >> On Mon, Sep 12, 2016 at 05:12:15PM -0700, Florian Fainelli wrote: >>> Hi, >>> >>> I have a root filesystem embedding filenames that look like these: >>> >>> /lib/data/: >>> >>> these are essentially files that can be matched against an USB >>> vendor/product id in an easy way. >>> >>> Now, the fun part is that this is only a problem when doing the >>> following (using OpenWrt/LEDE as a build system): >>> >>> 1: >>> - set CONFIG_INITRAMFS_SOURCE="" >>> - build kernel modules >>> - build my user-space tools >>> - build the kernel image >>> - reconfigure the kernel to now use an initramfs >>> - build the kernel w/ initramfs >>> >>> and then back to step 1 with the kernel build, would I hit this error: >>> >>> usr/Makefile:64: *** multiple target patterns. Stop. >> [...] >>> Which sorts of make sense here because the file name contains a ":" >>> which is not escaped, so GNU Make tries to interpret it. >>> >>> Now the part that does not quite make sense to me is why this file is >>> even relevant here considering that the first thing we do is set >>> CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically. >> >> It is possible that we read usr/Makefile twice for some reason. But the >> real problem is the lack of escaping. Can you try the following >> (untested) patch? > > Can you submit an official patch for this? Thanks a lot! The % escape is wrong. I'm trying to fix it or drop this escape. Michal