emerging genkernel works on mips and emerges 3.3.6 of genkernel, but when you go to use it it says.... ERROR: mips64 not yet supported by genkernel. Please add the arch-specific config file, /usr/share/genkernel/mips64/config.sh
Hrrmn... it's detecting as mips64 rather than mips, which is obviously causing the problem. Joshua, any ideas?
Looking in /usr/share/genkernel there is no mips or mips64 directory.
Just to note this is on an IP30 Octane system which is mips64.
First try genkernel 3.3.10 for me.
This gets furthur, but because I'm using USE="ip30" to get the patches for Octane I now get this problem from genkernel... Linux Kernel 2.6.14.4-mipsgit-20051030.ip30r10kl+ for mips... ERROR: Error: No kernel .config specified, or file not found. Now, the /usr/src directory has this... linux -> linux-2.6.14.4-20051030.ip30 linux-2.6.14.4-20051030.ip30 But the linux/Makefile in EXTRAVERSION has this... EXTRAVERSION = .4-mipsgit-20051030 So I tried changing this to.. EXTRAVERSION = .4-mipsgit-20051030.ip30 and didn't work, also EXTRAVERSION = .4-20051030 didn't work and finally, EXTRAVERSION = .4-mipsgit-20051030.ip30r10k+ didn't work. Even making another symlink with linux-2.6.14.4-mipsgit-20051030.ip30r10k -> linux didn't work.
Yes, the problem there is mips doesn't come with a "default" config due to the variety of the hardware; you manually have to specify one depending on hardware: i.e. genkernel [your-options] --kernel-config=/usr/share/genkernel/mips/ip30r10k-2005_1.cf for example.
If --kernel-config has to be specified, then that works.
Oh, I also had to use --kernel-cc=gcc because it looks for mips64-unknown-linux-gnu-gcc which seems to be the only binary missing as other mips64-unknown-linux-gnu-<as,ar,g++,ld> etc are there.
Oops, unfortunately this still fails when compiling klibc 1.1.1 and when compiling printf.c it reports... ../include/fcntl.h:12:30 klibc/archfcntl.h: No such file or directory.
Bizzarro </sealab> But aye, mips on genkernel is an adventure. 3.3.6 worked for me on the LiveCDs since I included several custom patches, but the bulk of these should be in 3.3.10, except for the static building patch which I've yet to re-draft. Also, genkernel on mips isn't tested so far as to build normal day-to-day kernels, It was patched up enough so that it could be used in Catalyst for generation of the various release targets. We try to encourage our users to build their kernels by hand to gain a better understanding of the myriad magic involved in making all these things work properly. That said, though, genkernel should work fine with the following changes: You'll need to edit the IP30 config in genkernel to remove the references to the initramfs archive, as the initramfs archive genkernel builds is geared specifically for LiveCDs (it contains probing code to look for the LiveCD root partition). It might still build the initramfs archive, but won't attempt to bundle it into the kernel. Lastly, mips64-unknown-linux-gnu-gcc is missing because it sounds like you don't have the kernel-compiler, gcc-mips64, merged. Octane's use a 64bit kernel, and thus, need a separate compiler to build them, as the system compiler is for 32bit userland building only.
O.k. Thanks for the insights. I've abadoned genkernel and building directly. Maybe genkernel 3.3.6 should have mips removed from it's list though. Additionally, I'd thought that the mips userland stuff was also 64bit, but I can see from your comments it's not, so I'll emerge gcc-mips64 to build the kernel. Will gentoo for mips switch to a 64bit compiler for userland at some point ??
Oh, one more thing on genkernel 3.3.10 is that without specifying --kernel-cc again it's looking for mips64-unknown-linux-uclibc-gcc (i.e. the uclibc one) rather than the gnu version. And genkernel 3.3.10 still fails to build because klibc 1.1.1 can't find klibc/archfcntl.h
(In reply to comment #11) > O.k. Thanks for the insights. I've abadoned genkernel and building directly. > > Maybe genkernel 3.3.6 should have mips removed from it's list though. > > Additionally, I'd thought that the mips userland stuff was also 64bit, but I > can see from your comments it's not, so I'll emerge gcc-mips64 to build the > kernel. > > Will gentoo for mips switch to a 64bit compiler for userland at some point ?? Not for a good long while. We're still using the 'o32' binary format, found in IRIX 5.x, which is strictly a 32bit environment. In the future, we hope to move to 'n32', which is the binary format found in IRIX 6.x, and it offers the pluses of a 64bit userland w/ the pluses of a 32bit userland (access to all the registers on a CPU w/o the 64bit overhead, for example). This is a ways off still, since glibc still has some work to do on getting n2 support into top-notch shape, plus there are quite assuredly a number of userland proggies out there that need cleanup work (hdparm is one such example). (In reply to comment #12) > Oh, one more thing on genkernel 3.3.10 is that without specifying --kernel-cc > again it's looking for mips64-unknown-linux-uclibc-gcc (i.e. the uclibc one) > rather than the gnu version. > > And genkernel 3.3.10 still fails to build because klibc 1.1.1 can't find > > klibc/archfcntl.h I tested a klibc-1.1.1 build on my Octane, and it built fine, so there might be some yet-undiscovered oddity when klibc is used in conjunction with genkernel and such. I'm working on testing netboot support for Catalyst, which is going to run me through this same build process, so if this error exists outside of your userland, then I'll probably bump into it and figure out what's going on. As for the uclibc bit, that's specified (most likely) in the mips/config.sh folder in genkernel. Ideally, our releases will be built in a uclibc environment because the resulting binaries are smaller. While this doesn't pertain as much to a LiveCD, it will pertain heavily to a netboot build, since we want those to be as tiny as possible. Thus, it's the default. Technically, for genkernel to work as a kernel builder for non-release purposes, it needs more fixes, namely: A) A switch to enable/disable the building/inclusion of the initramfs module, since this is what is causing your klibc build to fail. B) Static kernel building. Currently, genkernel tries to build a modular kernel and assumes you have configured as such. We've had a bit of a hit-or-miss history on modular kernels on, so for my release purposes mips, so I rigged genkernel to build static-only kernels to cut down on the kernel complexity and avoiding any nasty building issues. Most of this will probably happen when genkernel gets re-written from the ground up and these thoughts are taken into consideration in a new write up to be more robust and modular. I believe the schedule for such a re-write is to have it occur sometime in 2006, probably before 2006.1 is released by my guess, but the releng/genkernel team may have a better indicator than I do.
Okay, I see where this is coming from I think. Genkernel drags in its own copies of klibc and whatnot, thus genkernel's copy of klibc-1.1.1 is lacking the mips patch needed to force a mips64 system to report itself as mips. Christ, Tim; anyone of you guys able to apply the klibc-1.1-mips32.patch in dev-util/klibc/files to genkernel's copy of klibc? Suppose I need to knock that upstream eventually (After seeing if it affects us on n32 as well).
Okay, I see where this is coming from I think. Genkernel drags in its own copies of klibc and whatnot, thus genkernel's copy of klibc-1.1.1 is lacking the mips patch needed to force a mips64 system to report itself as mips. Chris, Tim; anyone of you guys able to apply the klibc-1.1-mips32.patch in dev-util/klibc/files to genkernel's copy of klibc? Suppose I need to knock that upstream eventually (After seeing if it affects us on n32 as well).
Can gentoo-sources for mips depend on gcc-mips64 to clear up this dependency ??
Whoops, I meant mips-sources obviously, not gentoo-sources.
Should this be FIXED now that we're using mdev instead of klibc/udev?
No response from MIPS or OP, I'm assuming it is FIXED now.
