linux-kernel - Re: Allow (O=...) from file

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:	Wed, 5 Dec 2007 22:37:03 +0100
From:	Erik Mouw <mouw@...linux.org>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Jay Cliburn <jacliburn@...lsouth.net>, linux-kernel@...r.kernel.org
Subject: Re: Allow (O=...) from file

On Wed, Dec 05, 2007 at 10:00:03PM +0100, Sam Ravnborg wrote:
> On Tue, Dec 04, 2007 at 09:04:33PM -0600, Jay Cliburn wrote:
> > Sam,
> > 
> > This piece of the top-level Makefile in current git causes an
> > out-of-tree driver Makefile to fail.
> > 
> > 101 ifdef O
> > 102   ifeq ("$(origin O)", "command line")
> > 103     KBUILD_OUTPUT := $(O)
> > 104   endif
> > 105 endif
> > 
> > The out-of-tree driver Makefile contains an O=... directive that
> > (correctly) does _not_ specify the kernel source dir, and apparently
> > isn't overridden by the command line either. If in the above Makefile
> > snippet I change "command line" to "file", my out-of-tree make
> > succeeds. What do you think about allowing O= to come from a file in
> > addition to the command line?
> 
> When you change "command line" to "file" you actually makes kbuild
> ignore the O=... value which is why it succeeds.
> The problem we solve with the error below is that in some case
> the Makefile for the kernel were overwritten.
> And I do not really understand why this does not happen in yours
> and Erik's case.

I just RTFM for GNU make, changing "command line" into "default" also
results in a succesful build.

> Anyway - the right fix seems to detect that the two directories
> are equal and then just ignore the O=... setting.
> But I am lacking time atm to fix it - only sparsely working on
> Linux the next few weeks.

Here's a clue: when I build with ARCH=x86, I get some warnings, but the
targz-pkg builds succesfully:

erik@...hur:~/git/linux-2.6 > make ARCH=x86 allnoconfig
[...]
erik@...hur:~/git/linux-2.6 > make ARCH=x86 targz-pkg
[...]
Kernel: arch/x86/boot/bzImage is ready  (#1)
/bin/sh /home/erik/git/linux-2.6/scripts/package/buildtar targz-pkg
`/home/erik/git/linux-2.6/System.map' ->
/`/home/erik/git/linux-2.6/tar-install/boot/System.map-2.6.24-rc4'
`/home/erik/git/linux-2.6/.config' ->
/`/home/erik/git/linux-2.6/tar-install/boot/config-2.6.24-rc4'
`/home/erik/git/linux-2.6/vmlinux' ->
/`/home/erik/git/linux-2.6/tar-install/boot/vmlinux-2.6.24-rc4'
`arch/x86/boot/bzImage' ->
/`/home/erik/git/linux-2.6/tar-install/boot/vmlinux-kbuild-2.6.24-rc4'

** ** **  WARNING  ** ** **

Your architecture did not define any architecture-dependant files
to be placed into the tarball. Please add those to
/home/erik/git/linux-2.6/scripts/package/buildtar ...

Tarball successfully created in
/home/erik/git/linux-2.6/linux-2.6.24-rc4.tar.gz

So it looks like the i386-x86_64 merge has something to do with it.


Erik

-- 
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)