While upgrading world (stable AMD64), v86d errored out without any helpful message. This is a bit of a blocker, as the world update can't complete properly. Bah. :) I did set "x86emu" in package.use, since according to the v86d README, this should be used for x86-64 builds. Note, however, that v86emu is NOT turned on by default in the ebuild, and judging by the README, it absolutely should be! It's turned off by default, so unless users notice on the upgrade that there's a new flag . . . I'm not sure whether or not it had any part in the compile error, though it does turn up in the output. Here's the text from /var/tmp/portage/sys-apps/v86d-0.1.3-r1/temp/build.log: >>> Emerging (1 of 14) sys-apps/v86d-0.1.3-r1 to / * v86d-0.1.3.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking v86d-0.1.3.tar.bz2 ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.24-gentoo-r7/build * Found sources for kernel version: * 2.6.24-gentoo-r7 >>> Unpacking source... >>> Unpacking v86d-0.1.3.tar.bz2 to /var/tmp/portage/sys-apps/v86d-0.1.3-r1/work >>> Source unpacked. >>> Compiling source in /var/tmp/portage/sys-apps/v86d-0.1.3-r1/work/v86d-0.1.3 ... config.h successfully created. You can run `make` now. make -w -C libs/x86emu make[1]: Entering directory `/var/tmp/portage/sys-apps/v86d-0.1.3-r1/work/v86d-0.1.3/libs/x86emu' klcc -c -march=athlon64 -O2 -pipe -fomit-frame-pointer -msse3 -I/usr/src/linux/include -Ilibs/x86emu -I. -I../../include -I../../include/x86emu -o decode.o decode.c open3: exec of /usr/lib/ccache/bin/x86_64-pc-linux-gnu-gcc -D__KLIBC__=1 -D__KLIBC_MINOR__=5 -D_BITSIZE=64 -fno-stack-protector -m64 -nostdinc -iwithprefix include -D__KLIBC__=1 -D__KLIBC_MINOR__=5 -D_BITSIZE=64 -I/usr/lib64/klibc/include/arch/x86_64 -I/usr/lib64/klibc/include/bits64 -I/usr/lib64/klibc/include -O -c -march=athlon64 -O2 -pipe -fomit-frame-pointer -msse3 -I/usr/src/linux/include -Ilibs/x86emu -I. -I../../include -I../../include/x86emu -o decode.o -x c decode.c failed at /usr/bin/klcc line 138 make[1]: *** [decode.o] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-apps/v86d-0.1.3-r1/work/v86d-0.1.3/libs/x86emu' make: *** [x86emu] Error 2 * * ERROR: sys-apps/v86d-0.1.3-r1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 1500: Called die * The specific snippet of code: * make KDIR=${KV_DIR} || die * The die message: * (no error message) $ emerge --info Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r7 x86_64) ================================================================= System uname: 2.6.24-gentoo-r7 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ Timestamp of tree: Wed, 04 Jun 2008 05:36:02 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe -fomit-frame-pointer -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O2 -pipe -fomit-frame-pointer -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LINGUAS="en" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" USE="3dnow X a52 acpi alsa amd64 berkdb bluetooth cairo cdr cli cracklib crypt cups dbus dri dvd dvdr dvdread encode flac fortran gdbm gif gnome gpm gtk hal iconv isdnlog jpeg lame libnotify lm_sensors mad mime mmx mp3 mpeg mudflap ncurses nptl nptlonly nvidia ogg opengl openmp pam pcre pdf perl png pppd python quicktime readline reflection session spell spl sse sse2 ssl startup-notification svg tcpd truetype unicode usb vorbis xml xorg zlib" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
This looks like a ccache/klibc issue. Are using ccache on that system? Have you tried reinstalling klibc prior to emerging v86d? As for x86emu, the flag doesn't do anything on x86_64, where the lrmi backend in not available. In the previous versions of v86d, lrmi was used on x86 and x86emu on x86_64. Now x86 users have the option of changing the v86d backend to x86emu.
(In reply to comment #1) > This looks like a ccache/klibc issue. Are using ccache on that system? Have > you tried reinstalling klibc prior to emerging v86d? I don't use ccache; it's not installed. Also, I've never run into this issue with the upgrades to previous versions of v86d, even when the klibc version remained the same. klibc version is latest stable, 1.5.8. I haven't had a kernel or klibc upgrade in awhile either. The weird thing is that recompiling klibc lets the v86d compile complete, so now it's properly upgraded. It doesn't always seem necessary to recompile klibc just before a v86d upgrade, so what's up with that? Should users get some kind of ewarn notice that they should re-merge klibc before attempting any v86d update? I don't think klibc or v86d should ever have to be touched by the user, frankly -- kernel updates should be all they ever need to do by hand. So, what can we do about this? Additional online documentation on gentoo.org? Elog messages in the ebuilds? > As for x86emu, the flag doesn't do anything on x86_64, where the lrmi backend > in not available. In the previous versions of v86d, lrmi was used on x86 and > x86emu on x86_64. Now x86 users have the option of changing the v86d backend > to x86emu. Perhaps this should be masked or otherwise made unavailable for x86-64 users then, just to avoid confusion. The use.local.desc entry isn't particularly helpful, so I had to download the source and find the README which indicated that x86emu was appropriate for 64-bit systems. If the flag doesn't do anything for 'em, why make it selectable for that arch, y'know?
(In reply to comment #2) > The weird thing is that recompiling klibc lets the v86d compile complete, so > now it's properly upgraded. Forgot to mention that I tried it with (the useless) USE="x86emu" and "-x86emu", and it built correctly both times.
(In reply to comment #2) > The weird thing is that recompiling klibc lets the v86d compile complete, so > now it's properly upgraded. Since klcc apparently tried to execute a ccache binary, my guess is that your last klibc upgrade was somehow broken. Now that you have recompiled klibc, the problem is gone. > It doesn't always seem necessary to recompile klibc just before a v86d upgrade, > so what's up with that? Should users get some kind of ewarn notice that they > should re-merge klibc before attempting any v86d update? I don't think klibc or > v86d should ever have to be touched by the user, frankly -- kernel updates > should be all they ever need to do by hand. Agreed. The reinstall of klibc is by no means required in any way by v86d. The only reason it was necessary in this case is that klcc apparently didn't work correctly. As for why that was, I have no idea :) > Perhaps this should be masked or otherwise made unavailable for x86-64 users > then, just to avoid confusion. The use.local.desc entry isn't particularly > helpful, so I had to download the source and find the README which indicated > that x86emu was appropriate for 64-bit systems. If the flag doesn't do anything > for 'em, why make it selectable for that arch, y'know? Good point. I've just filed bug #224987 and requested for the flag to be forcibly enabled on amd64.
