After running "crossdev --kernel 2.4.30 mipsel-linux-uclibc" to install a toolchain for my Asus WL-500gx, emerge world fails with: cross-mipsel-linux-uclibc/mips-headers (is blocking sys-kernel/linux-headers-2.6.11-r3) # equery list linux-headers [ Searching for package 'linux-headers' in all categories among: ] * installed packages [I--] [ ] sys-kernel/linux-headers-2.6.11-r3 (0) # equery list mips-headers [ Searching for package 'mips-headers' in all categories among: ] * installed packages [I--] [ -] cross-mipsel-linux-uclibc/mips-headers-2.4.28-r1 (0) # equery which mips-headers /usr/local/portage/cross-mipsel-linux-uclibc/mips-headers/mips-headers-2.4.28-r1.ebuild I suspect that crossdev should modify its copy of the mips-headers ebuild file to remove PROVIDE="virtual/os-headers"
# equery list crossdev [ Searching for package 'crossdev' in all categories among: ] * installed packages [I--] [ ] sys-devel/crossdev-0.9.12-r1 (0) # emerge --info Portage 2.1_pre4 (hardened/x86/2.6, gcc-3.4.5, glibc-2.3.6-r2, 2.6.12-co-0.7.1-hn11 i686) ================================================================= System uname: 2.6.12-co-0.7.1-hn11 i686 AMD Athlon(tm) MP 1800+ Gentoo Base System version 1.12.0_pre15 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-mp -Os -pipe -fomit-frame-pointer -mfpmath=sse -fPIC -w" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-mp -Os -pipe -fomit-frame-pointer -mfpmath=sse -fPIC -w" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks prelink sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com/ ftp://130.207.108.136/pub/gentoo ftp://130.207.108.135/pub/gentoo ftp://130.207.108.134/pub/gentoo ftp://gentoo.chem.wisc.edu/gentoo/" MAKEOPTS="-j4" PKGDIR="/usr/portage//packages/x86/" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow acl acpi acpi4linux atlas berkdb bitmap-fonts bzip2 crypt cups dga dlloader dnd dvd ethereal f77 fbcon flash gd glibc-omitfp gtk2 hardened ithreads joystick kdeenablefinal kdexdeltas ltsp mmx moznocompose moznoirc nptl nptlonly pam pic pnp radeon readline snmp sse ssl subversion tcpd tetex threads usb userlocales vim-with-x x86 xv zlib elibc_glibc kernel_linux userland_GNU video_cards_radeon" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS
*** Bug 124379 has been marked as a duplicate of this bug. ***
I'm fairly certain that the problem here is that our old 2.4 mips-headers ebuilds do not use kernel-2.eclass, which is the problem. I also seem to recall that porting them to kernel-2.eclass will not be trivial, and therefore this problem is likely to persist. Kumba can comment further on that... Anyway, is there any reason you can't use the 2.6 headers? I believe we are pretty close to getting rid of 2.4 headers anyway.
The 2.4 headers are never likely to be ported to kernel-2 because for the most part, they're deprecated as far as we're concerned. We follow upstream linux-mips.org development mainly, and they've all but abondoned 2.4.x so we're following suit. 2.6 headers/sources has been around long enough that most applicances should've ported to it by now, if they haven't, then there's not much we can do about it. If anyone in the embedded team wants to port the 2.4 headers ebuilds to kernel-2, they're more than welcome to.
> If anyone in the embedded team wants to port the 2.4 headers ebuilds to > kernel-2, they're more than welcome to. i ported linux-headers-2.4.26 to kernel-2 a while back and i use that for all my uClibc stages ...
Remember that at the end of the day, gentoo has an ebuild for gcc for bigger reasons than because it's a portage dependency. If the only things included in the portage tree are solely those needed for other apps in the portage tree, eventually we realize that if we haven't any apps, we provide any dependency, no bugs, and no late updates. It's dangerous to make value judgements, like what "should" be done by companies that aren't interested in extending the life of products they've already sold. Most appliances will never see any major updates from the manufacturer... who coincidentally is the only one who can write drivers ever since DMCA (and similar laws in other countries) made implementing proprietary protocols illegal. If I can't run crossdev gcc on my gentoo desktop, then that basically nullifies the GPL -- manufacturers basically can distribute linux without the flexibility that's supposed to accompany it. Oh yes, here's the source code for your firmware, but the toolchain you need requires an old version of this, that, and the other that won't run on any modern distro... Sorry about the rant, just trying to make a point that having 2.6.x everything doesn't obsolete 2.4.x any more than having python obsoletes bash... sure it's more powerful, but it's not a drop-in replacement. SpanKY, are you making your ebuilds available, or are they x86-only? Where would I get started learning about the kernel-2 eclass to make the necessary modifications? Is there any documentation beyond what's in the eclass source and a couple ebuilds that use it? Can someone recommend which ebuild I should start with? Modify the mips 2.4 ebuild to use kernel-2, or modify a 2.6 ebuild based on kernel-2 to install 2.4 headers?
I'm using the 2.4 headers because openwrt only supports the 2.4 kernel on my linksys router. It has to do with one or more of the kernel drivers being binary-only from the manufacturer. I know their project offers a pre-compiled x86 toolchain, but that doesn't fit seamlessly with my gentoo system. I want my own toolchain. I would also be willing to help out in getting the ebuild updated correctly -- the 2.4 kernel shouldn't be considered obsolete. I haven't ventured too far into ebuild development, but point me in the right direction and I'll try to come up with something. Where can I find documentation on porting to kernel-2?
> Remember that at the end of the day, gentoo has an ebuild for gcc for bigger > <snip> this really has no bearing at the end of the day, Gentoo devs do whatever interests them. 2.4 does not interest mips, thus it isnt being worked on. if this matters to you, provide a fix, dont expect the mips team to do it. > SpanKY, are you making your ebuilds available, or are they x86-only? the only ebuilds i use are in the tree > Can someone recommend which ebuild I should start with? why not use the version i suggested
> > Can someone recommend which ebuild I should start with? > > why not use the version i suggested That won't work for a couple of reasons. First of all, there are linux-mips specific fixes which won't be included in the linux-headers-2.4.26 ebuild. Secondly, you (Spanky) modified crossdev itself to use nothing but mips-headers for mips cross-toolchains. I suppose you could hack up crossdev to use linux-headers, and hack up linux-headers to apply a proper diff against the linux-mips.org tree, but whatever. Anyway, to reply to everyone at once here, the mips team can only support hardware for which we use, we own, and which interests us. The Gentoo/MIPS project is mostly about SGI hardware, with the mips Cobalt machines being secondary. Because the upstream linux-mips developers have essentially completely abandoned 2.4, particularly on all the hardware we support, we really can't do anything but go along with that. In many cases the hardware which we do development on has never worked with anything but a 2.6 kernel. Now, this *does* cause unrest with hardware vendors that would rather use 2.4, but Ralf Baechle (mips upstream kernel maintainer) has basically told them to suck it. I happen to know that the Openwrt kernel guys are rather unhappy about this, but there isn't much that can be done about it. Besides, like I already said, as soon as we can do so we're probably going to nuke the remaining mips-headers-2.4 ebuild from portage. As for openwrt, I really don't feel too bad about users not being able to use Gentoo to build a proper 2.4 toolchain to use in building openwrt packages and images. I know the openwrt guys have worked very hard to ensure that their default toolchain works properly with all of their packages and firmware images, just the same way that we work very hard to ensure that the Gentoo default toolchain works with all of our packages and kernels. I happen to use Openwrt on two routers, and I'm not even brave enough to try and use a Gentoo toolchain to build Openwrt firmware images because of the risk of incompatibilities.
