Re: [PATCH] Don't mkdir -p include/config in the sourcetree when using O=outputdir option

[John Kacur <jkacur@redhat.com>]

On Wed, Jan 6, 2010 at 9:45 PM, Michal Marek <mmarek@suse.cz> wrote:
> John Kacur napsal(a):
>> Yes, I doubled checked that the problem exists, and it is quite easy for me to
>> reproduce. However, my proposed solution is also broken, please don't
>> apply, I'm still investigating.
>>
>> I am surprised that you are not able to reproduce the problem though.
>> Did you follow the steps I that I outlined?
>
> I did
>
> $ git checkout v2.6.33-rc3
> $ mkdir /bld/2.6.33-rc3
> $ zcat /proc/config.gz >/bld/2.6.33-rc3/.config
> $ make O=/bld/2.6.33-rc3/ oldconfig
> ...
> hit Enter several times
> ...
> $ ls -ld include/config /bld/2.6.33-rc3/include/config/
> ls: cannot access include/config: No such file or directory
> drwxr-xr-x 2 mmarek users 4096 2010-01-06 21:35
> /bld/2.6.33-rc3/include/config//
> $ make O=/bld/2.6.33-rc3/
>  GEN     /bld/2.6.33-rc3/Makefile
> scripts/kconfig/conf -s arch/x86/Kconfig
>  Using /home/mmarek/linux-2.6 as source for kernel
>  GEN     /bld/2.6.33-rc3/Makefile
>  CHK     include/linux/version.h
>  UPD     include/linux/version.h
>  CHK     include/generated/utsrelease.h
>  UPD     include/generated/utsrelease.h
>  CC      kernel/bounds.s
> ... continues building ...
>
>
> The mkdir command has been in the Makefile since 2006 (c955cca), so I
> think that your problem is caused by something else. Try a make V=1
> build with a read-only source tree to see which mkdir command fails.
>

Michal: The length of time that a bug exists in a piece of code is no
argument for
it's correctness!

I tried to debug this using
make -d V=1 O=/bld/2.6.33-rc3
and discovered that the bug did not always occur, but did sometimes.
This leads me to think that it is timing sensitive, and indeed the
problem shows up
more easily on a machine with multiple processors.

Is it possible that the step with mkdir -p can sometimes occur in a
Makefile parallel process
before the cd KBUILD_OUTPUT occurs? That would explain why it doesn't
reliably reproduce.

In any case, the idea behind my original patch is good, just specify
the full path
using the objtree variable and the problem goes away. The first round of my
implementation was simply lacking.

Following up this note with a patch.

John