linux-kernel - Re: [PATCH v2 3/5] kbuild: Use relative path for $(objtree)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Jun 2014 07:09:32 -0700
From:	Randy Dunlap <rdunlap@...radead.org>
To:	Michal Marek <mmarek@...e.cz>
CC:	Richard Weinberger <richard.weinberger@...il.com>,
	linux-kbuild@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH v2 3/5] kbuild: Use relative path for $(objtree)

On 06/10/14 02:02, Michal Marek wrote:
> On 2014-06-10 01:47, Randy Dunlap wrote:
>> sure.  I did mkdir /tmp/O then
>> make ARCH=um SUBARCH=i386 O=/tmp/O defconfig
>> make ARCH=um SUBARCH=i386 V=1 O=/tmp/O
> 
> So I tried with the exact same paths and it worked for me:
> $ mkdir -p /local/lnx/next/linux-next-20140606
> $ git archive d4bc590f8716f7dde6b7bca319097ac30a8cb0b4 | tar xf - -C
> /local/lnx/next/linux-next-20140606/
> $ cd /local/lnx/next/linux-next-20140606/
> $ make ARCH=um SUBARCH=i386 O=/tmp/O defconfig
> $ make ARCH=um SUBARCH=i386 V=1 O=/tmp/O
> 
> and it worked.
> 
> 
>> make KBUILD_SRC= ARCH=x86 archheaders
>> make -C /local/lnx/next/linux-next-20140606 O=/tmp/O/. archheaders
>> make -C /tmp/O \
>> KBUILD_SRC=/local/lnx/next/linux-next-20140606 \
>> KBUILD_EXTMOD="" -f /local/lnx/next/linux-next-20140606/Makefile \
>> archheaders
>> make -f /local/lnx/next/linux-next-20140606/scripts/Makefile.build obj=arch/x86/syscalls all
> 
> Here, it should do
> 
>   /bin/sh
> '/local/lnx/next/linux-next-20140606/arch/x86/syscalls/syscallhdr.sh'
> '/local/lnx/next/linux-next-20140606/arch/x86/syscalls/syscall_32.tbl'
> 'arch/x86/syscalls/../include/generated/uapi/asm/unistd_32.h' 'i386' '' ''
>   /bin/sh
> '/local/lnx/next/linux-next-20140606/arch/x86/syscalls/syscallhdr.sh'
> '/local/lnx/next/linux-next-20140606/arch/x86/syscalls/syscall_64.tbl'
> 'arch/x86/syscalls/../include/generated/uapi/asm/unistd_64.h'
> 'common,64' '' ''
>   /bin/sh
> '/local/lnx/next/linux-next-20140606/arch/x86/syscalls/syscallhdr.sh'
> '/local/lnx/next/linux-next-20140606/arch/x86/syscalls/syscall_64.tbl'
> 'arch/x86/syscalls/../include/generated/uapi/asm/unistd_x32.h'
> 'common,x32' '' '__X32_SYSCALL_BIT'
>   /bin/sh
> '/local/lnx/next/linux-next-20140606/arch/x86/syscalls/syscalltbl.sh'
> /local/lnx/next/linux-next-20140606/arch/x86/syscalls/syscall_32.tbl
> arch/x86/syscalls/../include/generated/asm/syscalls_32.h
> 
> which is not happening in your case for some reason. Can you please
> check if you have some stale files in include/generated in the *source*
> tree?
> 
>     git ls-file -o --directory

I'm not using git, just tarballs.  I don't have an include/generated
subdirectory at all in my source tree.

However, today's linux-next builds OK for me (both i386 and x86_64),
so let's go with your patch.

> It could be that there is some include/generated directory from a
> previous in-tree build.


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/