Pretty standard .config that works with all kernels so far. This one bombs with said versions: CC kernel/sched.o CC kernel/fork.o CC kernel/exec_domain.o CC kernel/panic.o CC kernel/printk.o CC kernel/profile.o kernel/profile.c:206: error: __ksymtab_profile_event_unregister causes a section type conflict kernel/profile.c:205: error: __ksymtab_profile_event_register causes a section type conflict make[1]: *** [kernel/profile.o] Error 1 make: *** [kernel] Error 2 Same goes for gentoo-sources-2.6.22-r2. Switching back to gcc 4.1.x makes it build. Older kernels (I tried 21.6) die, too. Same spot, same error message.
OOps. fortgot emerge --info, here it is: Portage 2.1.3_rc8 (default-linux/alpha/2007.0/server, gcc-4.2.0, glibc-2.6-r0, 2.6.21.6 alpha) ================================================================= System uname: 2.6.21.6 alpha EV68AL Gentoo Base System release 1.12.10 Timestamp of tree: Mon, 30 Jul 2007 09:20:01 +0000 distcc 2.18.3 alpha-unknown-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.61-r1 sys-devel/automake: 1.9.6-r2, 1.10 sys-devel/binutils: 2.17.50.0.16 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r1 ACCEPT_KEYWORDS="alpha ~alpha" AUTOCLEAN="yes" CBUILD="alpha-unknown-linux-gnu" CFLAGS="-mieee -pipe -O2 -mcpu=ev67" CHOST="alpha-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-mieee -pipe -O2 -mcpu=ev67" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userpriv usersandbox" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://gentoo.mirror.solnet.ch" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync5.de.gentoo.org/gentoo-portage" USE="acl alpha apache2 bash-completion berkdb bitmap-fonts bzip2 cli cracklib crypt cups dri fortran ftp gdbm gpm iconv isdnlog libg++ mailwrapper midi mmap mudflap mysql ncurses nls nptl nptlonly offensive openmp pam pcre perl pppd python readline recode reflection session sharedmem snmp sockets spl ssl tcpd truetype truetype-fonts type1-fonts unicode vim vim-pager xml xorg zlib" ALSA_CARDS="ali5451 als4000 bt87x ca0106 cmipci emu10k1 ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 maestro3 trident usb-audio via82xx ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Note that this is the alpha dev machine. Alpha team members either have access or can easily get access. Poke yoswink or ferdy about it.
Is CONFIG_PROFILING enabled above? Can you try flipping it?
It wasn't active and I set it to "N", then when executing "make all", I said "N" to the OProfile Config option. That fixed the compile error for kernel/profile.o, but now it bombs here: CC drivers/input/input.o CC drivers/input/ff-core.o LD drivers/input/input-core.o CC drivers/input/mousedev.o CC drivers/input/keyboard/atkbd.o LD drivers/input/keyboard/built-in.o CC drivers/input/mouse/psmouse-base.o drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a section type conflict make[3]: *** [drivers/input/mouse/psmouse-base.o] Error 1 make[2]: *** [drivers/input/mouse] Error 2 make[1]: *** [drivers/input] Error 2 make: *** [drivers] Error 2
Argj. I set it to Y of course.
This affects ia64 as well. without CONFIG_PROFILING i get the same error as comment #0 with CONFIG_PROFILING i get this: CC drivers/acpi/resources/rsaddr.o CC drivers/acpi/resources/rscreate.o CC drivers/acpi/resources/rsinfo.o CC drivers/acpi/resources/rsio.o CC drivers/acpi/resources/rslist.o CC drivers/acpi/resources/rsmisc.o CC drivers/acpi/resources/rsxface.o drivers/acpi/resources/rsxface.c:477: error: __ksymtab_acpi_rs_match_vendor_resource causes a section type conflict make[3]: *** [drivers/acpi/resources/rsxface.o] Error 1 make[2]: *** [drivers/acpi/resources] Error 2 make[1]: *** [drivers/acpi] Error 2 make: *** [drivers] Error 2
http://article.gmane.org/gmane.linux.kernel/567165 has a patch that supposedfly fixes (part of) the problem. I tried said patch on the alpha dev machine. It cancelled the need for CONFIG_PROFILING=y but it still dies on the psmouse file.
OK, the patch is finally applied upstream (see URL).
Upstream has done only half-a-fix. I.e. they've only fixed Itanic. For Alpha, a still get: CC drivers/input/mousedev.o CC drivers/input/keyboard/atkbd.o LD drivers/input/keyboard/built-in.o CC drivers/input/mouse/psmouse-base.o drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a section type conflict distcc[12254] ERROR: compile drivers/input/mouse/psmouse-base.c on 172.17.1.9 failed make[3]: *** [drivers/input/mouse/psmouse-base.o] Error 1 make[2]: *** [drivers/input/mouse] Error 2 make[1]: *** [drivers/input] Error 2 make: *** [drivers] Error 2 with 2.6.23-rc3 and gcc 4.2.0
Bah...same error as Tobias on ia64...what a fix, jeez.
Reported upstream.
And building 2.6.23-rc7 with gcc 4.2.0 fails in exactly the same way.
Same story with 2.6.23.
This may be a known issue: I tried patching my gcc-4.2.2 with the suggested patch in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490 and the issue I saw while building the kernel "section type conflict" went away. I have not tried to boot the resultant kernel yet, however. Tested with 2.6.23.9 vanilla kernel in an ia64 cross compile environment (on x86) with a hacked ebuild of gcc-4.2.2.
This is really a GCC bug that is being addressed upstream. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
Hmm? people seem to think its a kernel issue now. http://www.gossamer-threads.com/lists/linux/kernel/876795
This is fixed by changeset 91d35dd93e14c34539a8005183ea500f25caad02 which is part of 2.6.25-rc2.
I confirm...
queued for 2.6.23 and 2.6.24
Fixed in genpatches-2.6.23-10 (gentoo-sources-2.6.23-r9) and genpatches-2.6.24-4 (gentoo-sources-2.6.24-r3)
