Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 86924 - 2.6.x kernel can't be compiled with gcc-3.4.x with the current unmasked ( version of binutils
Summary: 2.6.x kernel can't be compiled with gcc-3.4.x with the current unmasked (2.14...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: MIPS Linux
: High blocker (vote)
Assignee: MIPS Porters
Depends on:
Reported: 2005-03-27 19:59 UTC by Dave Andruczyk
Modified: 2005-03-30 11:37 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Dave Andruczyk 2005-03-27 19:59:27 UTC
The linux-2.6.12-rc1-20050320 kernel for mips (cobalt qube 2) can NOT be compiled with the current unmasked versions of binutils/gcc. the binutils is too old...

current unmasked binutils is

current gcc: gcc version 3.4.1 20040803 (Gentoo Linux 3.4.1-r3, ssp-3.4-2, pie-

The failure during kernel build is (make -V=1):

   ld  -m elf32ltsmip  -r -o mm/built-in.o mm/bootmem.o mm/filemap.o mm/mempool.o mm/oom_kill.o mm/fadvise.o mm/page_alloc.o mm/page-writeback.o mm/pdflush.o mm/readahead.o mm/slab.o mm/swap.o mm/truncate.o mm/vmscan.o mm/prio_tree.o mm/fremap.o mm/highmem.o mm/madvise.o mm/memory.o mm/mincore.o mm/mlock.o mm/mmap.o mm/mprotect.o mm/mremap.o mm/msync.o mm/rmap.o mm/vmalloc.o mm/page_io.o mm/swap_state.o mm/swapfile.o mm/thrash.o mm/shmem.o

ld: final link failed: Bad value
make[1]: *** [mm/built-in.o] Error 1

According to these mesgboard posts at:
the version of binutils needed is  This ebuild for this version (r1) version doesn't even have a mips keyword in it.  

I'm temporarily adding it in my local portage on my qube and will try building it and the kernel to see if it succeeds and post back..
Comment 1 Dave Andruczyk 2005-03-28 06:40:52 UTC
After adding the mips keyword to the newer binutils installing that and running a "make clean ; make" in the kernel dir the kernel built cleanly and booted up with no problems.

Please add the mips keyword and unmask it for binutils- so that people can build the kernel on the mips (cobalt) platform with the newer GCC that is currently unmasked (3.4.1)

Comment 2 Stephen Becker (RETIRED) gentoo-dev 2005-03-28 07:32:14 UTC
Both your compiler and binutils versions are known to work.  I have compiled many mips kernels using binutils and the various flavors of gcc 3.4.x.  Also, we can't just add a stable keyword to a package that had no keywords...that would be a major violation of QA policy.  I suggest you accept ~mips keywords for now, that will give you binutils I believe.  This version should also work.

Something to consider is that you may have a b0rked kernel config.  Also, out of curiosity, how much RAM do you have?
Comment 3 Dave Andruczyk 2005-03-29 05:48:39 UTC
The current unmasked compiler and binutils DO NOT compile the 2.6.10 and 2.6.12 kernel.... the link errors will result. ld: final link failed: Bad value.  This happened AFTER an "emerge world -uDa" which upgraded GCC among about 30 other things..

however after installing the newer binutils, the kernel compiled fine and booted up.  Initially it hung at IDE detection for HDC/HDD,  but appending "hdc=none hdd=none idebus=33" in  the boot line in /boot/default.colo allowed it to bootup and it appears to be running fine..  The other mips forums (not on know this is a documented problem and the fix was to use the newer binutils ( as it has some fixes that have to do with GCC-3.4.x

This is (Linux mips 2.6.12-rc1-mipscvs-20050320) 08:47:41                                                                     
qube login:
Comment 4 Stephen Becker (RETIRED) gentoo-dev 2005-03-29 06:40:10 UTC
What you seem not realize is that we are more than just a mipsel port for cobalt.  There is a very good reason that is latest stable.  On our big endian n32 userland, none of the 2.15 versions will compile glibc.  You also seem to have ignored my statement that we *can't* take an unkeyworded ebuild and send it directly to stable.  It is not only bad QA, it is against Gentoo policy.

Anyway, our main (only) cobalt guy assured me he has compiled cobalt kernels just fine with that same binutils+gcc combination.  If it really doesn't work for you, I suggest you either run ~mips, or you learn how to use /etc/portage to unmask the versions off stuff you want.  See "man portage" for this.

One more time I will ask how much RAM you have?  Kumba speculated that it may be a memory issue with the older binutils.

Also you might consider not getting so testy and demanding on bugzilla, as it won't help you any.
Comment 5 Dave Andruczyk 2005-03-29 16:27:14 UTC
The cobalt has 64 megs of RAM, and over 512 MB of swap,  when it fails to link no more than 8 megs of swap was used. 

Well, the 2.6.10 kernel could be built AFTER the system was first installed from a netboot (via the handbook instructions),  but AFTER the emerge sync/emerge world -uDa completed a kernel (the same one actually) could NOT BE BUILT (link errors, due to the newer GCC/binutils combo from the emerge world update),  the stable unmasked devel tools from the emerge world BREAK on 2.6.10/12  that's the problem I'm trying to bring across..  using the later binutils SOLVES that problem (and doubtlessly brings in a lot more problems, that I haven't ran into yet)

Perhaps a good solution in portage is to change "mips" into "mipsel" for little endian mips, and mips or something like "mipsbe" for big endian mips archs

But as it sits now the current devel environment that is unmasked for mips is broken for the cobalt qube 2 series.
Comment 6 Stephen Becker (RETIRED) gentoo-dev 2005-03-30 11:37:44 UTC
Heh...our arch team is way too small to split things into big and little endian like that.  Really, most stuff works just as good on either BE or LE.  Anyhow, binutils- and binutils- are both stable now.  With USE="multislot" they will coexist on your system with no problems, however you will need to install binutils-config if you haven't already.  I suggest upgrading from to -r2 first, then setting USE="multislot" and emerging the ebuild.

On a side note, you might consider getting more RAM.  We generally discourage folks from installing gentoo/mips with less than 128mb of RAM.  Often, gcc and/or glibc has serious problems compiling on mips otherwise.