From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Sat, 23 Jan 2016 13:55:47 +0100 Subject: [Buildroot] Analysis of build failures In-Reply-To: <56a3731081d58_57eded0b847233a@ultri2.mail> References: <56a3731081d58_57eded0b847233a@ultri2.mail> Message-ID: <20160123135547.1d8da414@free-electrons.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Ricardo, First of all, thanks a lot for this great investigation! Definitely very useful! On Sat, 23 Jan 2016 10:33:20 -0200, Ricardo Martincoski wrote: > This error occurs when applying a patch that changes a file with spaces > in the name. > When applying a patch generated by diff v3.3 (the newest version [2]), > the tool patch needs to be version 2.7 or any later to ensure any patch > will be applied. > libsoil is the only package today that patches a file with space in the > name. Aah, this explains the problem. My build server has patch version 2.6. > Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch v2.7 > is from 2012 [2]). > http://patchwork.ozlabs.org/patch/572097/ Not really acceptable, as we want to support old distros. Especially when this is really needed only for one package. > Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch > v2.5.9 is from 2004 [2]), address on the manual > 'Format and licensing of the package patches' the workaround needed when > a file changed by a patch has spaces in its name, apply the workaround > to libsoil (either use diff 3.2 or manually remove the quotes from the > filename inside the patch). Seems like the best solution. Can you cook such patches (both to the manual, and the change to libsoil) ? BTW, why would we need to require patch >= 2.5.9 ? Just to support file name with spaces ? > Solution 3: Create host-patch. Almost every package would depend on it. > I don't known if it would be feasible since gcc has patches. We only build gcc for the target, so we could certainly build host-patch. However, this really seems overkill to solve the problem of just one package, for which there is a separate solution (your solution 2). Thanks again for your investigation. I'm looking forward to seeing your patches implementing solution (2). Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com