On Fri, 30 Mar 2007 01:35:39 -0400, Kumba <kumba@xxxxxxxxxx> 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
