/var/tmp/portage/app-emulation/vmware-modules-271.1-r1/work/vmci-only/linux/driver.c:127:4: error: implicit declaration of function ‘__devexit_p’ [-Werror=implicit-function-declaration] Reproducible: Always
Created attachment 339346 [details, diff] Git formatted patch to build on linux 3.8 This should apply over the vmware overlay.
Updating the summary, since this also affects vmware-modules-264.5.
(In reply to comment #1) > Created attachment 339346 [details, diff] [details, diff] > Git formatted patch to build on linux 3.8 > > This should apply over the vmware overlay. Since vmware-modules are also failing in main portage I guess it should be applied there as well (also - you have attached patch to ebuild instead of actual patch).
(In reply to comment #3) > (In reply to comment #1) > > Created attachment 339346 [details, diff] [details, diff] [details, diff] > > Git formatted patch to build on linux 3.8 > > > > This should apply over the vmware overlay. > > Since vmware-modules are also failing in main portage I guess it should be > applied there as well (also - you have attached patch to ebuild instead of > actual patch). Sorry - it was me misunderstanding the bugzilla GUI.
If user have user namespace support enabled it still does not work: CC [M] /var/tmp/portage/app-emulation/vmware-modules-271.1-r1/work/vmblock-only/linux/control.o /var/tmp/portage/app-emulation/vmware-modules-271.1-r1/work/vmblock-only/linux/inode.c:49:4: warning: initialization from incompatible pointer type [enabled by default] /var/tmp/portage/app-emulation/vmware-modules-271.1-r1/work/vmblock-only/linux/inode.c:49:4: warning: (near initialization for 'RootInodeOps.lookup') [enabled by default] /var/tmp/portage/app-emulation/vmware-modules-271.1-r1/work/vmblock-only/linux/inode.c: In function 'InodeOpLookup': /var/tmp/portage/app-emulation/vmware-modules-271.1-r1/work/vmblock-only/linux/inode.c:138:32: error: incompatible types when assigning to type 'kgid_t' from type 'int' make[3]: *** [/var/tmp/portage/app-emulation/vmware-modules-271.1-r1/work/vmblock-only/linux/inode.o] Error 1
I doubt it's feasible right now to patch the module for user namespaces. Many other parts of the kernel aren't compatible with it, such as NFS and CIFS. I could be wrong, and it might be trivial, but maybe not.
How about applying this patch?: http://communities.vmware.com/thread/432897
(In reply to comment #7) > How about applying this patch?: > > http://communities.vmware.com/thread/432897 It is the same patch as attached.
I was about to report a bug, but found this one. I don't think that the proposed patch is correct though. Jason's patch will of course compile, but doesn't have the same effect as the original macro in all cases. If we look at the 3.7.x sources __devexit_p is defined like this: /* Functions marked as __devexit may be discarded at kernel link time, depending on config options. Newer versions of binutils detect references from retained sections to discarded sections and flag an error. Pointers to __devexit functions must use __devexit_p(function_name), the wrapper will insert either the function_name or NULL, depending on the config options. */ #if defined(MODULE) || defined(CONFIG_HOTPLUG) #define __devexit_p(x) x #else #define __devexit_p(x) NULL #endif In 3.8, it looks like the "best" match is not the simple removal of the usage, but a differently named macro. 3.8 has the following: #ifdef MODULE #define __exit_p(x) x #else #define __exit_p(x) NULL #endif So it looks like the "proper" solution is simply use __exit_p instead of __devexit_p. I will attach a patch as well.
Hmm, looking deeping, I may have been mistaken. 3.7.x also had the __exit_p macro. It seems that __devexit and related were tied to hotplug which simply doesn't have some of the macros that were used previously. simply removing the usage of the macros seems to make sense.
Fixed in 271.2 (ws 9.0.2).
Created attachment 342570 [details, diff] vmware modules 264 patch for 3.8.x Any chance we can have a patch applied to the version for vmware 8.x? Here's a quick and dirty patch I've cooked up. Appears to at least fix the issue for the vmci stuff.
(In reply to comment #6) > I doubt it's feasible right now to patch the module for user namespaces. > Many other parts of the kernel aren't compatible with it, such as NFS and > CIFS. I could be wrong, and it might be trivial, but maybe not. Right now, if any of those incompatible kernel parts are enabled, CONFIG_USER_NS is force-disabled. I had to disable CIFS to get USER_NS in. So this problem is "fixed" this way. See bug #462666 for the user namespace issue.
Patch added, thanks.
