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: <4CC702EB.1000301@zytor.com>
Date:	Tue, 26 Oct 2010 09:33:47 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jan Beulich <JBeulich@...ell.com>,
	Alexander van Heukelum <heukelum@...tmail.fm>,
	Ingo Molnar <mingo@...e.hu>, akpm@...ux-foundation.org,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	David Howells <dhowells@...hat.com>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers
 in brackets

On 10/26/2010 03:53 AM, Maciej W. Rozycki wrote:
> 
>  Also note that *.*.9x versions are snapshots from the FSF repository (so 
> there's no fixed date associated with them), which also delegates 
> maintenance responsibility to whoever packages them and makes available to 
> people.  In the state as imported from the repository they may have odd 
> problems or grave bugs, as exhaustive regression testing is generally only 
> made after a release branch has been created and otherwise changes to the 
> head of the tree are only tested for a limited subset of targets before 
> they are applied.  Therefore local fixes are inevitable for them anyway.
> 

Well, sort of... the x.x.9x releases used in production -- specifically
the ones with a numbering scheme like x.x.9x.0.x -- in the Linux world
tend to be the ones maintained and released by H.J. Lu:

http://www.kernel.org/pub/linux/devel/binutils/

>  And last but not least binutils are one of the easier tools to build from 
> sources, so installing a newer version, especially when it comes to native 
> tools (hardly anyone uses cross-compilation targeting x86, I believe), 
> somewhere under $HOME to use for kernel builds is a trivial effort:
> 
> $ ./configure --prefix=$HOME/somewhere && make && make install
> $ PATH=$HOME/somewhere/bin:$PATH
> 
> Certainly much easier than building the kernel, especially when it comes 
> to selecting the right configuration options.

Yes, although there is also a version dependency between binutils and
gcc, as I unhappily found out trying to run an upversion gcc on an old
distro at one point.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ