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, 21 Dec 2010 00:46:12 +0100
From:	Michal Marek <mmarek@...e.cz>
To:	Arnaud Lacombe <lacombar@...il.com>
Cc:	"Carlos R. Mafra" <crmafra2@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Mauro Carvalho Chehab <mchehab@...hat.com>
Subject: Re: Build regression: unknown option "visible"

On 20.12.2010 18:37, Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Dec 20, 2010 at 12:22 PM, Carlos R. Mafra<crmafra2@...il.com>  wrote:
>> After pulling latest git from Linus (v2.6.37-rc6-132-g55ec86f)
>> I can't compile it anymore:
>>
>> [mafra@...ar:linux-2.6]$ make -j2 O=/mnt/ext4/kernel-output/
>>   GEN     /mnt/ext4/kernel-output/Makefile
>> scripts/kconfig/conf --silentoldconfig Kconfig
>> drivers/i2c/algos/Kconfig:6: unknown option "visible"
>> drivers/media/common/tuners/Kconfig:48: unknown option "visible"
>> drivers/media/video/Kconfig:115: unknown option "visible"
>> drivers/media/dvb/frontends/Kconfig:16: unknown option "visible"
>> make[3]: *** [silentoldconfig] Fehler 1
>> make[2]: *** [silentoldconfig] Fehler 2
>>
>> This was introduced by 37e3273ee52f ("media/video: convert Kconfig
>> to use the menu's `visible' keyword"), but I did a quick search
>> and apparently I am the only one with a broken build.
>>
>> In any case, that's a regression for me and therefore I'm reporting it.
>>
>> I can test patches etc and provide more info if needed.
>>
> Did you build from a clean tree or a dirty one ?
>
> I know these is issue with Kbuild where the parser will not get
> updated to the new version if the target already exist but is older
> than the current "shipped" one.

Yes, if you build kconfig in the source tree and then do another build 
in a separate directory (make O=/some/where), the build system will not 
detect this and happily use generated kconfig files from the previous 
build attempt. I really should fix this given the pace of kconfig 
development lately :-).

Michal
--
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/

Powered by blists - more mailing lists