Hello, I don't know if it should work... but as there are arguments I think it should supported... genkernel --menuconfig --mrproper --install --kernel-cross-compile=<prefix> --utils-cross-compile=<prefix> --utils-arch=<arch> --bootdir=/tmp/<arch> --arch-override=<arch> all Some issues I found: 1. menuconfig does not work with --arch-override, I must set ARCH environment in order to make it work. 2. strip should be replaced with ${UTILS_CROSS_COMPILE}strip 3. busybox should set USING_CROSS_COMPILER to y and CROSS_COMPILER_PREFIX to ${UTILS_CROSS_COMPILE} if ${UTILS_CROSS_COMPILE} is not empty. 4. make (compile_generic) utils should not set CC, AS, LD as environment or as make arguments, it makes autoconf build fail. 5. autoconf package should have --host=$(echo "${UTILS_CROSS_COMPILE}" | sed 's/-$//') or similar. I guess there are more, I don't know if you wish to support this or not... But it will be great if you do! Thanks.
AFAIK, this has been broken for a *long* time. I tried to use --arch-override ~2 years ago to build a x86_64 kernel on my i686 box when I was switching from my Athlon t-bird to Athlon64 X2 machine. It didn't really work back then, and it didn't seem like there was much interest in fixing it, since the demand for it is so low. If this one is going to get fixed, you'll probably have to submit a patch for it.
Thank you, I guess I need to submit a patch, just wanted to know if upstream wishes it to work... It will not be enough for a single cleanup, as someone will need to continue maintaining it in future versions...
Again, since it's seldom used, it will probably just bitrot again. Although, I can't imagine that it will bitrot all that quickly if it's fixed up properly.
A quick look at the code shows that the commandline option should work just fine. How are you calling genkernel?
See comment#0. But it cannot... at least (2) will never work... Many issues maybe will be solved if you override the compiler, linker etc... But I think that the --utils-cross-compile=<prefix> should do the job.
Specifying --arch-override=foo on the commandline does nothing but set ARCH to "foo" in the env, which is why I say it should work. Although, I can confirm at least point 1. When I run 'genkernel --menuconfig --arch-override=sparc64 all' on my x86_64 box, genkernel shows "* Linux Kernel 2.6.20-gentoo-r4 for sparc64..." and then menuconfig has x86_64 options. I imagine this one is relatively easy to fix. I'll take a look.
Created attachment 129308 [details, diff] export ARCH It looks like all we need to do is export ARCH for menuconfig to be able to see it. This simple patch takes care of #1.
Maybe a good solution for cross compile would be to emerge packages such as cross-XXXX which will cache contents at some place instead of recompile them in genkernel? Something like: cross-<arch>/busybox with ROOT in cache directory. Then we can manage the USE flags and integrity correctly.
We don't want anything that requires the underlying system to be Gentoo. I want to be able to build the exact same kernel on a Debian x86 system and a Gentoo PPC system. I want to be able to build a LVM-enabled kernel on a system without having LVM installed. Everything needs to be generalized and abstracted. I've been working on this for a while now, but it is a slow and arduous process. The main point is that we do not add anything which works against said goal, as it will only increase the workload later.
OK. I just added the ARCH patch, but haven't touched any of the other stuff.
This patch was reverted due to bug 198440
For this to go forward, we need to export a kernel-compatible ARCH string, not just the raw ARCH from portage. The toolchain-funcs.eclass has 'tc-arch-kernel' that returns the correct arch for any given CTARGET/CHOST string.
I agree. However, this won't happen until gk 3.5. Any patch submitted against current SVN would undoubtedly not apply later on when we're ready for it.
Patches can be sent againt the git repository at git://git.wolf31o2.org/projs/genkernel and they will be tested for the next genkernel release.
PS: Adding keyword "Inclusion" and "[patch] " prefix to better show this bugs nature in searches...
I am demoting this from IN_PROGRESS to CONFIRMED given that we are approaching the six-year mark. Also, has anyone tried doing this recently? I am fairly certain that catalyst somehow hooks into genkernel, so it should not be too hard to modify genkernel to make this work.
cross compilation support in genkernel is pointless and has been in a broken state for ages. Moreover, almost all the append_* functions would need to be fixed. We should drop cross compilation support completely, even because it's actually not working.
I think this is a dead codepath, based on the lack of interest over the years.
