When I try to emerge nfs-utils, I get errors about undefined variables and so forth. Reproducible: Always Steps to Reproduce: 1. emerge nfs-utils Actual Results: The compile failed, output from emerge nfs-utils attached. Expected Results: Compiled and installed nfs-utils. Portage 2.0.49-r15 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.6.0-test9) ================================================================= System uname: 2.6.0-test9 i686 Pentium III (Coppermine) Gentoo Base System version 1.4.3.10 distcc 2.11.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O3 -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 /usr/X11R6/lib/X11/xkb /opt/tomcat/conf /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://ftp.up.ac.za/mirrors/gentoo.org/gentoo ftp://137.215.40.41" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://ftp.up.ac.za/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 gdbm berkdb slang readline arts aalib svga java mysql sdl gpm tcpd pam ssl perl python esd imlib oggvorbis gtk qt kde motif opengl mozilla cdr X gtk2 -gnome -bonobo"
Created attachment 21681 [details] Output from "emerge nfs-utils"
Looks like you have linker errors before the undefined variables. Try it with MAKEOPTS="-j1"
Excact same problem. Actually, if you look inside the ebuild(/usr/portage/net-fs/nfs-utils/nfs-utils/nfs-utils-1.0.6.ebuild) you will note that in the src_compile function there is # parallel make still fails make || die "Failed to compile" This for me is an indication that this is a known problem that parallel makes fail. For the MAKEOPTS to become active src_compile should use emake if I understand it correctly. I actually suspect a missing dependancy, but I have no idea what. Just an idea, but nfs is part kernel, therefor I suspect that these programs would need kernel sources to compile correctly, right? Could it be that something has changed from 2.6.0-test9 to 2.6.0-test10 that prevents nfs-utils from compiling?
You're right about the parallel make stuff. I didn't look at the ebuild. Since I'm running 2.4 here instead of 2.6 I can't verify the failure. I'll throw this over to the kernel crowd for a look though.
It works fine on test9 at home (on another machine). It also works fine on test10 on the office machine - there goes that idea. In which headers is MOUNTPROG supposed to be defined? So I grep for MOUNTPROG in the /usr/include directory and I come up with nix include # grep MOUNTPROG -r * grep: warning: gnome-xml/libxml: recursive directory loop rpcsvc/mount.h:#define MOUNTPROG 100005 rpcsvc/mount.x:program MOUNTPROG { nix include # And on the non-working machine: pug include # grep MOUNTPROG -r * rpcsvc/mount.h:#define MOUNTPROG 100005 rpcsvc/mount.x:program MOUNTPROG { pug include # This is really cruel. might it be that an include path somewhere gets set incorrectly? I note that whilst compiling (or at least in the files that is left over after failure the following files remain: nfs-utils-1.0.6/support/export/mount.h nfs-utils-1.0.6/support/include/mount.h How can I check whether this is the case?
I just found that bug 12391 is basically the same, the only difference seems to be the version. As such, almost want to consider this bug as confirmed (but I can't confirm my own bug). As mentioned on bug 12391 I have already checked nfs support in the kernel, I do have it. Do we have any other ideas?
can you attach both mount.h's from the build dir and the one from your /usr/include dir?
Created attachment 21848 [details] /usr/tmp/portage/nfs-utils-1.0.6/work/nfs-utils-1.0.6/support/export/mount.h
Created attachment 21849 [details] /usr/tmp/portage/nfs-utils-1.0.6/work/nfs-utils-1.0.6/support/include/mount.h
Created attachment 21850 [details] /usr/include/rpcsvc/mount.h
Those are the lot, I think. I've also tried doing emerge -e nfs-utils and after a couple of hours the same failures occured (at least I had time to customise my desktop :). Any other things I could try?
I've just found bug 34984, which might or might not be related. I also suffer from that same problem.
Sorry, that is bug 34910. And nfs-utils does compile against test9 on the same machine. I don't know whether we can consider this closed, but I suspect this issue will pop up again when people start switching to the 2.6.0 kernel. Can anybody else confirm that this is in fact correct? In which case we should probably close and inform the upstream developers?
K, we won't be able to fix this here, we need upstream developers to fix their code, I'm closing this here, for now, just make sure that /usr/src/linux does *NOT* exist, ensure that you have linux-headers emerged and build nfs-utils against that.
