On Fri, 30 Mar 2007 01:35:39 -0400, Kumba <kumba@gentoo.org> 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
> > CONFIG_BUILD_ELF64?
> [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
CONFIG_BOOT_ELF32 or CONFIG_BOOT_ELF64. The word BOOT and BUILD seems
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
|