Summary: | failure to emerge nfs-utils | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jaco Kroon <jaco> |
Component: | [OLD] Server | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | mr_bones_ |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Output from "emerge nfs-utils"
/usr/tmp/portage/nfs-utils-1.0.6/work/nfs-utils-1.0.6/support/export/mount.h /usr/tmp/portage/nfs-utils-1.0.6/work/nfs-utils-1.0.6/support/include/mount.h /usr/include/rpcsvc/mount.h |
Description
Jaco Kroon
2003-12-04 02:29:12 UTC
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. |