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]
Message-ID: <F86C52D5-02DB-441D-AC8B-FC5169CAF182@zytor.com>
Date:	Mon, 29 Feb 2016 23:39:29 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	sedat.dilek@...il.com, Ingo Molnar <mingo@...nel.org>
CC:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-next <linux-next@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: linux-next: build failure after merge of the tip tree

On February 29, 2016 11:28:22 PM PST, Sedat Dilek <sedat.dilek@...il.com> wrote:
>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar <mingo@...nel.org> wrote:
>>
>> * Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> After merging the tip tree, today's linux-next build (x86_64
>allmodconfig)
>>> failed like this:
>>>
>>>   DESCEND  objtool
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>>   MKDIR   
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>>> compilation terminated.
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>>> builtin-check.c:28:20: fatal error: string.h: No such file or
>directory
>>> compilation terminated.
>>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>>> compilation terminated.
>>>
>>> and further errors ...
>>>
>>> This build is done with a PowerPC hosted cross compiler with no
>glibc.
>>
>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>linux-next
>> dependent on it?
>>
>>> I assume that some things here need to be built with HOSTCC?
>>
>> I suspect that's the culprit. Do you now mandate people to have
>PowerPC systems as
>> a requirement to merge to linux-next? How are people supposed to be
>able to test
>> that rare type of build method which does not matter to 99.99% of our
>kernel
>> testers and users?
>>
>
>>From my experience in using different $COMPILER you should always pass
>CC and HOSTCC in your make-line when building a Linux-kernel or
>playing with the Kconfig-system.
>
>When building my llvm-toolchain with make/autoconf I had also to pass
>CC and CXX to my configure-line otherwise you got misconfiguration.
>
>[ EXAMPLE: Linux Kconfig-system ]
>
>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>HOSTCC=$COMPILER"
>
>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>silentoldconfig < /dev/null
>
>- Sedat -

That is not the issue here.  The problem is clearly that objtool is a host program and not compiled with host cc.  So it is a good thing to test even though it is weird, because it affects real use cases.

As x86 is far and beyond the most widely used host architecture, cross-compiling x86 is more likely to involve compiler differences than actually using another host, or possibly compiling 32 bits on a system without the 32-bit libc installed, but it should still work.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ