There are problems linking the current kernel sources with the latest version of binutils (2.13.90.4) available on Gentoo 1.4b . Compiling the sources works but there are a lot of "unresolved symbols" errors" when it comes to installation. binutils <= 2.11 shouldn't be affected by this problems. I think it's a major problem since you won't get a usable kernel after bootstrapping your system with the default-x86-2.0 profile.
Have you actually tried the kernel? AFAICT, these messages are safe to ignore. Anyhow, I compiled my kernel with >= 2.11, ignored those messages, and haven't had a single issue since. The modules work fine, as well. This is probably just more crap from the nice people over at gnu who are obsessed with pendantic warning messages and notifications, even when you didn't ask for them.
Actually my fresh baken kernel doesn't get along with modprobe. I have to insmod them. Anyways, I mentioned that binutils <= 2.11 are not affected by this problem. This is not correct since I successfully built a kernel using binutils-2.12.90.0.7. The first problems encountered when using binutils >= 2.12.90.0.15. There are definitely linker problems, not only warnings. ;) One time there was a workaround for this by removing the "*(.text.exit)" entry from the DISCARD part of vmlinux.lds in /usr/src/linux/arch/<architecture>/ .
I can confirm this: build fresh Gentoo-1.4 with GCC 3.2 compile kernel gento-sources-2.4.19-r7: I get lots of unresolved symbols during make modules_install going back to binutils 2.12.90.07 seems to correct this: kernel build went fine ... going to reboot now ...
As Nicholas Wourms commented, they are safe to ignore (as i did), but then you should insmod the modules in the correct order by hand (no depmod means no modprobe :/). There is a real serious problem, isn't a matter of pedantic warnings. By the way, it blocks Gentoo-1.4 base installation.
Ok, here's a little summary about what I've found out the last few hours: If you're installing from a Gentoo 1.4b ISO you will recognize that it uses "binutils-2.13.90.0.4" as default. By changing the default binutils version defined in /usr/portage/profiles/default-x86-2.0/packages from "binutils-2.13.90.0.4" to "binutils-2.12.90.0.7" it will bootstrap "binutils-2.12.90.0.7" while keeping the precompiled "binutils-2.13.90.0.4" on your system. Kernel should work well since you are compiling with your bootstrapped version although the precompiled version is still installed. Well, the main problem of the latest binutils version is not binutils itself but the current available version of modutils under Gentoo. I'll keep you up2date if binutils works with modutils-2.4.19. If this should happen I'll apply a new ebuild of modutils that hopefully solves this bug.
I think the breakage may be even more serious than this. I can't get verification from elsewhere, but I've upgraded to GCC3.2 and the default-x86-2.0 profile (which is Gentoo 1.4b as I understand it). (Almost) everything was fine (and had been up and running, compiling stuff, etc. for about a day), until i "upgraded" to the new binutils. After that I have not been able to compile *ANYTHING* dynamically. Not even "Hello, world" works. If I compile statically everything seems to still work fine. I cannot for the life of me remember any other packages that I've installed/upgraded since the upgrade to GCC3.2 that could have caused this, so I think this version of binutils needs to be masked until further investigation is possible.
Created attachment 3246 [details] modutils-2.4.19.ebuild (important update!!) This should resolve bug #6730. Versions of modutils <=2.4.16 in cunjunction with binutils >=2.12.90.0.15 will break kernel sources. With this version of modutils kernel building works like a charme. Watch the Changelog within the modutils package for more information.
I tried Tobias' ebuild and am pleased to report it worked for me as well. Thanks Tobias!
Thanks for the ebuild. It seems to work in by box.
Stealing bug.
Just to add to this: binutils-2.13.90.4 WILL break if you compile it with GCC3.2 and use "-fomit-frame-pointer" and you probably won't notice until it's too late. The binaries compile and install, but are FUBAR. I've verified this by trying two separate bootstrap.sh runs from stage1-1.4b tarballs in chroots. The run with "-fomit-frame-pointer" ON fails after compiling and merging binutils; trying to compile "hello world" afterwards results in a binary which immediately segfaults. The run with "-fomit-frame-pointer" OFF works fine. IMHO the binutils tarballs should either: 1) OVERRIDE the CFLAGS in the environment/make.conf with its own (known working) CFLAGS (i used plain old '-O3'). 2) REMOVE "-fomit-frame-pointer" from the CFLAGS variable. (Using the flag-o-matic eclass this should be trivial to do). This may not be that important during bootstrap since most users won't tweak CFLAGS until after bootstrapping, but if binutils are upgraded after installation this can break the installation completely (as it did in my case).
> IMHO the binutils tarballs should either: D'oh. Of course i meant "binutils ebuild".
Well, new modutils is in place, and Verwilst fixed the compile problem. Closing this ..
Just tried this after running into the problem--well done, as always--it fixed my modules_install errors immediately. Thank you so much. Sincerely, Scott Robbins
I seem to be able to compile a kernel with 2.14.90.0.6-r6 binutils with -fomit-frame-pointer using gcc 3.3.2 (and bison 1.875 of course). It compiles fine. My emerge --info is below. Portage 2.0.49-r15 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r1, 2.6.0-test9) ================================================================= System uname: 2.6.0-test9 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.4.3.10 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -Os -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /var/bind /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-xp -Os -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://gentoo.noved.org/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://www.gtlib.cc.gatech.edu/pub/gentoo http://212.219.247.20/sites/www.ibiblio.org/gentoo/ http://212.219.247.14/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg libg++ libwww mad mikmod mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib alsa gdbm berkdb slang readline arts aalib bonobo svga tcltk java guile sdl gpm tcpd pam ssl perl python esd imlib oggvorbis gnome gtk qt motif opengl mozilla ldap cdr X ipv6 gtk2 gnome esd arts tiff mpeg jpeg png mng 3ds aalib qt tcltk 3dnow mmx sse -kde dvd wmf offensive alsa oss openal opengl mozsvg mozcalendar mozaccess mozp3p mozxmlterm cdr" I clipped the -fomit-frame-pointer from the filter-flags directive. Basicly, it compiled using my cflags. I'm having no troubles, so you may want to look into this. Next I'm going to try bootstrapping gcc 3.3.2 with gcc 3.3.2 and compiling it with -fomit-frame-pointer, so wish me luck. I have binary packages of my working ones. --Bluefox Icy
