Hi, On Thu, Jan 13, 2011 at 11:57 AM, Philippe Auphelle <pauphelle@xxxxxxxxx> wrote: > OK, problem solved, case closed! > > Now in case this can help someone else, the whole recipe follows, and > it should work for generating various x86 kernels of any bitness from > a single 32-bit or 64-bit Linux, AND from there out-of-tree modules. > It just requires the regular native x86 gcc toolchain (post 4.2.2 > version) for either 32 or 64-bit x86, no cross compiler, no nuttin', > just (may be) all or part of the packages corresponding on your distro > to debian's lib64gcc1.deb, libc6-amd64.deb, libc6-dev-amd64.deb and > g++4.4-multilib.deb > Since I already had those installed, I couldn't check what part, if > any, was needed to kbuild to x86_64. > > What I wanted to do was to configure and prepare kernel configs for > 32-bit and 64-bit x86 kernels in “remote” directories, i.e. in > directories that were out of the kernel source tree. > The linux.com page mentioned below is about the only source I found > for detailed info about handling multiple kernel targets with kbuild, > with all the gory details, explanations, do's and don't: > > http://www.linux.com/learn/linux-career-center/29812-the-kernel-newbie-corner-building-and-running-a-new-kernel > > Then it took me some time to figure out a peculiar behavior of make > menuconfig : make menuconfig does NOT prompt for 64-bitness UNLESS it > is called with an ARCH setting like: > > make ARCH=x86 O=/home/foo/2.6.35-24-generic-x86_64 menuconfig > > The trick is to set ARCH=x86. When using ARCH=x86_64, not only does > "make menuconfig" NOT prompt for bitness, but it does NOT set bitness > to 64-bit either. > I knew that 64-bit prompt existed because I had seen once before, > during my previous (and failed) attempts, but couldn't figure out how > I had triggered it (and why I couldn't see it again). And it took me > quite a while to figure this one out! > (side note): > What I would ideally expect menuconfig to do is this: > When ARCH= is set to any form of x86 (be it x86, x86_64, i386 or > X86_32), I would expect menuconfig to show the prompt for bitness, > with the 64-bit prompt preset by menuconfig according to the ARCH > value that was provided. I suppose this would be just as useful for > other non-x86 ARCH targets that have variable bitnesses, too. > > Anyway, the whole process to kbuild an x86_64 external module from a > 32-bit x86 machine is thus: > Create a specific .config file set for 64-bit in a remote directory, > using something like: > make ARCH=x86 O=/home/foo/2.6.35-24-generic-x86_64 menuconfig > > Use > make ARCH=x86_64 O=/home/foo/2.6.35-24-generic-x86_64 modules_prepare > to prepare the remote kernel tree for external module building (see > Documentation/kbuild/modules.txt, “ How to build external modules”). > > Or (preferably) use a plain make > make ARCH=x86_64 O=/home/foo/2.6.35-24-generic-x86_64 > to run a full kernel build. The later is most likely better, since as > Arnaud mentoned above, Documentation/kbuild/modules.txt says: > > NOTE: "modules_prepare" will not build Module.symvers even if > CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be > executed to make module versioning work. > > CAVEAT: > On the modules_prepare or plain build make operations, note that one > MUST use the ARCH=x86_64 (and NOT the ARCH=x86 such as "make > menuconfig" wants). Otherwise, the make will be done for a 32-bit > target and will immediately fail somehow because of mismatching > options between the .config file and the make logic. > > I just completed the full x86_64 kernel build, that worked perfectly, > and I do have a brand new x86_64 object kernel tree in my "remote" > target directory. And yes, all the .ko are x86_64 ones, too. ;-) > And following this, my own make for my external module happily cranked > out an x86_64 external module. > > Thanks for your help! /PhA. > Going though this, I think you went on the wrong mailing list as what you describe is mostly how the x86 folks setup their stuff, not a kbuild/kconfig per-se, as tools, issue(s). I guess you should address any request to them directly. - Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
