# /usr/bin/crossdev.sh --arch=mipsel * crossdev.sh v0.2 - Cross-Toolchain Generator * Host Architecture: i686-pc-linux-gnu * Host CFLAGS: -march=i686 -mcpu=i686 -O2 -pipe * Target Architecture: mipsel-unknown-linux-gnu * Target CFLAGS: -mips3 -mabi=32 -O2 -pipe * Install Path: /home/crossdev/mipsel * Using unstable packages... Off * Enabling extra gcc langs... Off * Building Kernel Compiler... Off * Cleaning build dir... Off * Pretending... No * The following packages in /usr/portage will be used: sys-kernel/mips-headers-2.4.21-r3 sys-devel/binutils-2.14.90.0.6-r6 sys-devel/gcc-3.2.3-r3 sys-libs/glibc-2.3.2-r3 * Cross-compile will begin in 5 seconds... <snip> --------------------------------------------------------------------------- * >>> Stage 2: Configure, Build, & Install glibc-core * >>> --------------------------------------------------------------------------- * Configuring sys-libs/glibc-2.3.2-r3 (full)... <snip> checking size of long double... 8 running configure fragment for ../sysdeps/pthread running configure fragment for ../sysdeps/unix/sysv/linux checking for egrep... (cached) grep -E checking installed Linux kernel header files... TOO OLD! configure: error: GNU libc requires kernel header files from Linux 2.0.10 or later to be installed before configuring. The kernel header files are found usually in /usr/include/asm and /usr/include/linux; make sure these directories use files from Linux 2.0.10 or later. This check uses <linux/version.h>, so make sure that file was built correctly when installing the kernel header files. To use kernel headers not from /usr/include/linux, use the configure option --with-headers. * glibc failed to configure! </end>
This is very odd. Tell me, did you adjust the MIN_KV value in /etc/crossdev/crossdev.conf to anything other than the default (2.4.16)? That's about the only thing that I can think of that would make glibc complain. I've built a mipsel full cross-compiler just fine on my Duron system because I have a Cobalt RaQ2 to test stuff with.
funny. >> # /etc/crossdev/crossdev.conf.example didn't even know there was a conf file! I discovered this bug by complete accident, it looks as if I need --arch=mips and not --arch=mipsel now. I'm currently in the process of building, what looks to be so far so good, --arch=mips. I just hope the only thing wrong is that crossdev will simply revert to defaults (or something just as sane as the crossdev.conf.example). Lemme know if you need any other info on this bug with --arch=mipsel (of which doesn't appear to be what i needed installed now). Using an intel P3 platform (eh laptop).
--arch=mips builds a toolchain for a big-endian MIPS system, i.e., SGI Machines. --arch=mipsel builds for MIPS little endian, like DEC stations and the Cobalt RaQ/Qube (1 & 2) line. And yes, the top lines of crossdev.sh define sane defaults, and then checks for the existance of the config file. If the config file exists, any defaults are overwritten when the contents of the conf file are imported. Why glibc still bonked out on you intrigues me, as the defaults should have worked (I believe I set MIN_KV to 2.4.16, but I'll have to double check. I have some tweaks I still need to push out for a new crossdev release anyways.
yup. MIN_KV is set to 2.4.16 in the example conf. However, even --arch=mips is borking too. Here it is again after a rm -rf /home/crossdev/* and clean: (I have linux-2.4.23 installed with a symlink point to linux -> /usr/src/linux-2.4.23-test/) checking for egrep... (cached) grep -E checking installed Linux kernel header files... TOO OLD! configure: error: GNU libc requires kernel header files from Linux 2.0.10 or later to be installed before configuring. The kernel header files are found usually in /usr/include/asm and /usr/include/linux; make sure these directories use files from Linux 2.0.10 or later. This check uses <linux/version.h>, so make sure that file was built correctly when installing the kernel header files. To use kernel headers not from /usr/include/linux, use the configure option --with-headers. * glibc failed to configure!
oops -- mis-posted that, kernel header versions are: * sys-kernel/linux-headers Latest version available: 2.4.19-r1 Latest version installed: 2.4.19-r1
What version of glibc is it trying to install? Also, mips uses sys-kernel/mips-headers, not linux headers. Are you running unstable, or stable on this machine? This is rather odd...I fail to understand why glibc is griping about headers. Worked fine for me, but then again, glibc and gcc seem to be very fickle packages.
Also, cat /home/crossdev/mips/include/linux/version.h And paste the output here
oops -- mis-posted that, kernel header versions are: * sys-kernel/linux-headers Latest version available: 2.4.19-r1 Latest version installed: 2.4.19-r1 # cat /home/crossdev/mips/include/linux/version.h cat: /home/crossdev/mips/include/linux/version.h: No such file or directory however, /home/crossdev/mips/* is somewhat populated. sys-kernel/mips-headers [ Masked ] Latest version available: 2.4.22-r1 Latest version installed: [ Not Installed ] also, mips-sources are uninstalled
okay, the fact that version.h is missing is why glibc is failing. Why it is missing is interesting. Are you wable to post the output of the first stage, installing kernel headers, as an attachment to this bug by chance so I can see what what it's doing? It *should* execute "make oldconfig" on the kernel sources to produce the appropriate heads, then copy those headers out and into /home/crossdev/<arch>/include.
yea, nothing in include/ $ ls /home/crossdev/mips/include/ $ 3 roger # crossdev.sh --arch=mips --clean * crossdev.sh v0.2 - Cross-Toolchain Generator * Host Architecture: i686-pc-linux-gnu * Host CFLAGS: -march=i686 -mcpu=i686 -O2 -pipe * Target Architecture: mips-unknown-linux-gnu * Target CFLAGS: -mips3 -mabi=32 -O2 -pipe * Install Path: /home/crossdev/mips * Using unstable packages... Off * Enabling extra gcc langs... Off * Building Kernel Compiler... Off * Cleaning build dir... On * Pretending... No * The following packages in /usr/portage will be used: sys-kernel/mips-headers-2.4.21-r3 sys-devel/binutils-2.14.90.0.6-r6 sys-devel/gcc-3.2.3-r3 sys-libs/glibc-2.3.2-r3 Here's the source of the bug (i think): * Unpacking /usr/portage/sys-libs/glibc/glibc-2.3.2-r3.ebuild... >>> md5 src_uri ;-) glibc-2.3.2.tar.bz2 >>> md5 src_uri ;-) glibc-linuxthreads-2.3.2.tar.bz2 eutils flag-o-matic gcc >>> Checking glibc-2.3.2.tar.bz2's mtime... >>> Checking glibc-linuxthreads-2.3.2.tar.bz2's mtime... >>> Checking nptl-0.28.tar.bz2's mtime... >>> WORKDIR is up-to-date, keeping... * Copying mips-headers-2.4.21-r3/work/linux-2.4.21 -> /var/tmp/portage/crossdevbuild... cp: cannot stat `./mips-headers-2.4.21-r3/work/linux-2.4.21': No such file or directory ^ :-/ ^
Okay, I see the problem. I made a behavioral change in the way mips-headers installs itself some time ago. It unpacks to WORKDIR/linux-<VERSION>-mipscvs-<CVSDATE> now, instead of linux-<VERSION> (mips-based sources come from the linux-mips CVS server on a periodic basis, denoted by a date in YYYYMMDD format). I'll have to think of a workaround to crossdev to allow it to look in WORKDIR and detect the directory name (probably a well placed "find" command. Not sure when I'll get to this. I have several pending updates to crossdev that I've backlogged....Might try shortly.
ok. i'll be watching for the next couple of days/weeks.
Might actually be in a few hours.. Started tweaking it last night with some additional things I had backlogged, and almost done. If you're not already subscribed, you might join up to the gentoo-embedded mailing list, that's where I'll announce a new crossdev version when it gets pushed ouyt into portage. Also, since you're building for mips, what kind of mips system are you targetting? one of the SGI Machines, or a embedded device? I help run the Gentoo/MIPS port, so you might be interested in some of our work as well.
ok. looks like i might have missed your posting already to gentoo-embedded. can the modified ebuild be posted here? Or will it be added to portage within a few hours? trying to compile apps for the linksys wrt54g (wireless router... it runs a linux kernel within it's flash ram system, of which, hackers are really tearing it up and adding allot of neat new features to it ;-). Also, the linksys wrv54g also uses a similar setup. I'm not sure if cross-compiling apps for teh wrt54g will work, but from one users experience, it did work w/o apperant problems. But since then, Linksys has released full source including an already compiled version of mips building tools -- i'm somewhat of one of those generic guyz that just likes to do things natively .
I added it to portage earlier tonight. The mailing lists were down due to a server move, and the resulting DNS catchup, but should be back now. I have yet to announce the 0.3 release there. Took a little longer as I added a few more archs to the main script, and made some of the evil code in the status script more readable. Let me know how it works.
zlib decompression support (CONFIG_ZLIB_INFLATE) [N/y/m/?] zlib compression support (CONFIG_ZLIB_DEFLATE) [N/y/m/?] *** End of Linux kernel configuration. *** Check the top-level Makefile for additional configuration. *** Next, you must run 'make dep'. rm -f include/asm ( cd include ; ln -sf asm-mips asm) * Copying Linux Headers to /home/crossdev/mips/include... * >>> --------------------------------------------------------------------------- * >>> Stage 3: Configure, Build, & Install binutils * >>> --------------------------------------------------------------------------- * Configuring sys-devel/binutils-2.14.90.0.6-r6... /usr/bin/crossdev.sh: line 994: ../configure: No such file or directory * binutils failed to configure! ;-) maybe a "./{binutils folder}/configure" ? -- just a guess.
Blah. I built a cross-compiler fine before I released it (and a mips one too). Hmm, paste the 'ls' output of /var/tmp/portage/crossdevbuild, and if there is a binutils folder, the 'ls' of that too.
Still alive here? This seems to be a random issue others have run into, but I can't replicate myself. Dunno what the problem is. Have you run into it anymore recently?
I borked my wrt54g linksys router... So the only messing around with teh firmware that I'll be doing is re-re-trying to flash a good firmware copy to it (or manually removing the flash chip to insert a socket in order for a replacement chip... or some other solution.
No longer valid, but any issues reported should be fixed in crossdev-0.4. Re-open if this is not the case.
let's close this now
Arg, sorry wrong bug
There