[Top] [All Lists]

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

Subject: Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely
From: Atsushi Nemoto <>
Date: Fri, 30 Mar 2007 15:09:12 +0900 (JST)
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
On Fri, 30 Mar 2007 01:35:39 -0400, Kumba <> wrote:
> > So I should ask you again, does current git (or 2.6.20-stable) kernel
> > compiled by binutils-2.17/gcc-4.[12] work for IP32 if you disabled
> [snip]
> > So I had thought CONFIG_BUILD_ELF64=n worked for IP32...
> If memory serves, yes, it'll boot, because it's close to the old way I that I 
> used to use when building them.  Prior to 2.6.17, I did CONFIG_BUILD_ELF64=n 
> with -mabi=o64.  This let me use the plain 'vmlinux' target without any 
> special 
> changes.  2.6.17 is when I stopped using gcc-3.x for kernels, moved to 4.x, 
> and 
> started using CONFIG_BUILD_ELF64=y w/ -msym32 and friends.  Thus I now use 
> vmlinux.32.  I was told that that was the RightWay(TM) to do it.

IMHO here is a root of confusion.  The -msym32 option is/was enabled
only if CONFIG_BUILD_ELF64=n.  The vmlinux.32 thing are controled by
too umbiguous ;)

> Hence, the real point of this long chain is mainly to accomplish two things:
> 1) Finally determine the OneTrueWay(TM) to build 64bit kernels for our three 
> main CKSEG0-based systems (ip22, ip32, cobalt), and get that way documented 
> so 
> as to avoid confusion in the future.
> 2) Get a solution into the tree that does #1, and does it well.  So far, 
> Frank's 
> patch seems like the leading contender here.

Yes.  I agree.

And I think the answer is

1) Disable CONFIG_BUILD_ELF64 in short term.

2) Apply Franck's patchset with a slight change (enclose -msym32 by
   $(call cc-option)).

And _if_ this did not work on IP32, something needs to be fixed, but I
can not see why for now.

Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>