[lfs-dev] linux-3.4 needs patch to build

Fernando de Oliveira famobr at yahoo.com.br
Tue May 29 17:04:59 PDT 2012

On 29-05-2012 14:51, Ken Moffat wrote:
> On Tue, May 29, 2012 at 10:07:38AM -0600, Matthew Burgess wrote:
>> On Tue, 29 May 2012 09:02:17 -0700 (PDT), Fernando de Oliveira wrote:
>>> Digging into this since yesterday evening, discovered first that 3.4 is
>>> dev and stable version is 3.3.7, second, the error is well known:
>>> http://us.generation-nt.com/answer/linux-next-build-failure-after-merge-final-tree-help-207537361.html
>> 3.4 is *not* dev.  See http://kernel.org/ - 3.4 is 'mainline', 3.3.7 is stable.  But, as
>> soon as Greg releases 3.4.1, that will be deemed 'stable' as well.

One thing I forgot to say. Yet at the time of writing this message,
it can be read at the top of http://kernel.org/ home page:

Latest Stable Kernel:

Since yesterday, I saw the announcement of 3.4 at 2012-05-20 and 3.3.7
at 2012-05-21 and discovered many discussions regarding what problems
with the former. Some of them explicitly consider they should fix many
problems and I remember one telling that "this (git) kernel even
if compiled, will be corrupted" or something like that.

This led me to thinking they had hold back the release, because if
"latest stable" is 3.3.7 then 2.4 is not stable, i.e., although the
"mainline" is 3.4, it is not yet stable. With due respect, please,
forgive me for still asking (1) if this conclusion is wrong; (2) isn't
"not yet stable" equivalent to "dev"?


>  When I first saw the thread on lkml last week, I *thought* it was
> to do with relocatable kernels (presumably CONFIG_RELOCATABLE).
> Fernando, do you have that config option enabled ?
> ĸen

Thank you very much for replying, Ken.

Yes, I do have it enabled in all 5 machines. I believe it is not
essential for me, but I always liked the idea of relocatable code, since
my long gone assembler days. Do you think it is better to disable? But
again, only one misbehaved in build. All 5 are on now. I will try to
find differences and similarities between them.

With his option having been checked, please, any other ideas will be
also greatly appreciated.


More information about the lfs-dev mailing list