TIMELINE: I had kernel-2.6.15-r1 with nvidia-kernel-1.0.8756 working for a long time (very happily). This nvidia driver was at the time most recent in ~ARCH kernel-2.6.16-r7 come out and decide to upgrade to that. When I go and do a "emerge nvidia-kernel" the kernel driver compiles BUT with missing symbols warning "unknown symbol pci_find_class" "unknown symbol remap_page_range" It still compiled so I tried it out and rebooted. I got an error in the INIT output that modprobe could not insert "nvidia" module. There was an entry in /var/log/messages reporting the missing symbols. ... New nvidia driver (nvidia-kernel-1.0.8762) comes out so I go and emerge that. I first tried it against my working kernel (kernel-2.6.15-r1) but that now started producing those missing symbols warnings. I also tried it against kernel-2.6.16-r7 and it still produces the same missing symbols problem. I decide to mask nvidia-kernel-1.0.8762 so that I can then use nvidia-kernel-1.0.8756 with kernel-2.6.15-r1 (NOTE this was the combination that was working!). THIS now produces the same missing symbols warning and as a result could no longer boot into a working desktop!!! I thought it might be due to the kernel compiled with a different GCC with respect to the version used to compile nvidia-kernel. I recompiled kernel-2.6.15-r1 and also tried "emerge nvidia-kernel" BUT it still resulted in the missing symbols statement and thus no way of getting a working desktop! I decided to then just try and run the NVIDIA script directly Fluid ~ # sh /usr/portage/distfiles/NVIDIA-Linux-x86-1.0-8762-pkg1.run THIS brought me to a curses-like NVIDIA screen and I went through the instruction THIS sussefully made the nvidia module. I was then able to go modprobe nvidia and then /etc/init.d/xdm restart and I was able to get to a working desktop!!! RECAP a previous working kernel and nvidia combination that use to work stopped working using portage to create kernel module results in warnings about missing symbols (warnings that turn into ERRORS if you try to use the module) only way to get the driver is to run the NVIDIA script directly since portage uses the nvidia-script as well (as part of the emerge process, just to unpack it) the fact that using the script directly works YET using emerge does not implies that PORTAGE is somehow modifying the compile process that is breaking the correct compiling of nvidia-kernel emerge --info Fluid ~ # emerge --info Portage 2.1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.16-gentoo-r9 i686) ================================================================= System uname: 2.6.16-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.12.1 ccache version 2.3 [enabled] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 2.0.0_rc1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -fforce-addr -pipe -fomit-frame-pointer -ftree-vectorize -mmmx -msse" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2 -march=pentium4 -fforce-addr -pipe -fomit-frame-pointer -ftree-vectorize -mmmx -msse -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://mirrors.blueyonder.co.uk/sites/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://mirror.switch.ch/mirror/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/ ftp://ftp.solnet.ch/mirror/Gentoo http://www.mirror.ac.uk/mirror/www.ibiblio.org/" LINGUAS="en_GB" MAKEOPTS="-j2" 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'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/gentopia /usr/local/xgl-coffee" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acpi aim alsa avi berkdb bitmap-fonts bluetooth bonobo browserplugin bzip2 cairo canvas cdr cli crypt cups directfb dri dvd dvdread eds emboss encode esd extensions fbcon firefox flac foomaticdb fortran gdbm geoip gif gimpprint glitz gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml hal imlib inkjar insecure-savers ipv6 isdnlog java joystick jpeg jpg kqemu ldap libg++ libwww mad mikmod mme mme2 mmx mmx2 mono motif mozsvg mp3 mpeg mplayer msn nautilus ncurses nls nntp nomotif nptl nptlonly nsplugin nvidia ogg opengl oss pam pcre pdf pdflib perl pic plotutils plugin png ppds pppd python quicktime readline real reflection samba sdl session softmmu spell spl sse sse2 ssl svg swat tcpd truetype truetype-fonts type1-fonts udev unicode usb vim-with-x vorbis win32codecs xinerama xml xml2 xorg xprint xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_en_GB userland_GNU video_cards_nv video_cards_nvidia video_cards_vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I second this bug report. I switched from kernel 2.6.14-gentoo-r5 to 2.6.16-gentoo-r9 and then rebuilt the nvidia-kernel. That is where I started gettin the missing symboles error message. I'm using nvidia-kernel-1.0.6629-r5 though (geforce FX Go 5650) -------------------- emerge --info Portage 2.1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r3, 2.6.16-gentoo-r9 i686) ================================================================= System uname: 2.6.16-gentoo-r9 i686 Intel(R) Pentium(R) M processor 1500MHz Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf" CXXFLAGS="-O2 -march=pentium-m -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.inode.at/ ftp://ftp.easynet.nl/mirror/gentoo/ http://gentoo.mirror.icd.hu/ http://ftp.easynet.nl/mirror/gentoo/" LINGUAS="en" MAKEOPTS="-j2" 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'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/sci" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac acpi alsa apache2 apm avi bitmap-fonts bluetooth bzip2 cdr cli crypt cups divx4linux dri dvd dvdr emboss encode foomaticdb fortran freetype gd gif gimp gimpprint gpm gstreamer gtk gtk2 imlib ipv6 isdnlog joystick jpeg libg++ libwww mad matroska mikmod mmx mmxext motif mp3 mpeg msn musepack musicbrainz ncurses nls nptl nptlonly nvidia ogg oggvorbis opengl oscar pam pcre pdflib perl png ppds pppd python quicktime readline real reflection scanner sdl session spell spl sse sse2 ssl tcltk tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis wifi win32codecs wma wxwindows xinerama xml xorg xosd xprint xscreensaver xv xvid yahoo zlib elibc_glibc kernel_linux linguas_en userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I tried this with the 8762 driver and it works, no unknown symbols... There are some other problems though, but they'd be off-topic here.
I got the same missing symbol error after I built a new kernel 2.6.17. So I tried re-emergeing nvidia-kernel and I didn't get the missing symbol error the second time. Attached are the two emerge logs of nvidia-kernel.
Created attachment 89608 [details] media-video:nvidia-kernel-1.0.8762:20060620-072251.log Here's the first merge where I get the unknown symbols
Created attachment 89609 [details] media-video:nvidia-kernel-1.0.8762:20060620-075021.log Here's the second log, that's only 28 minutes later.
Just noticed I forgot my emerge --info, oops. Also, after I rebooted, I was able to load the nvidia module fine, but if I tried to run X, I got the error message below: NVRM: This version of the Linux kernel does not provide the vmap() NVRM: kernel interface. If you see this message, please update NVRM: your kernel to Linux 2.4.22 or install a distribution kernel NVRM: that supports the vmap() kernel interface. NVRM: RmInitAdapter failed! (0x53:0xffffffff:1088) NVRM: rm_init_adapter(0) failed Not sure this is related, but I think it may be, as after rebooting and again attempting to emerge nvidia-kernel i get the unknown symbols. $ emerge --info Portage 2.1.1_pre1-r1 (default-linux/amd64/2006.0, gcc-4.1.1/amd64-vanilla, glibc-2.4-r3, 2.6.16-gentoo-r9 x86_64) ================================================================= System uname: 2.6.16-gentoo-r9 x86_64 AMD Athlon(tm) 64 FX-55 Processor Gentoo Base System version 1.12.1 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: 0.4.2-r1 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 2.0.0_rc1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.16 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-mtune=athlon-fx -march=athlon-fx -O3 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-mtune=athlon-fx -march=athlon-fx -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache confcache distcc distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://192.168.1.105/ http://gentoo.llarian.net/ http://mirror.datapipe.net/gentoo http://gentoo.cites.uiuc.edu/pub/gentoo/ http://gentoo.mirrors.easynews.com/linux/gentoo/" LANG="en_US.utf8" LC_ALL="en_US.utf8" 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'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://192.168.1.105/gentoo-portage" USE="amd64 X a52 aac acpi alsa asf avahi avi berkdb bitmap-fonts bzip2 cddb cdparanoia cli crypt dbus dlloader dri dts dvd eds emboss encode ffmpeg firefox flac foomaticdb fortran gdbm gif glitz gnome gpm gstreamer gtk gtk2 gtkhtml hal ieee1394 imlib ipod isdnlog java jpeg logrotate lzw lzw-tiff mad mono mp3 mp4 mpeg mysql nautilus ncurses nfs nls nptl nptlonly nsplugin nvidia ogg opengl pam pcre pdf pdflib perl png pppd python qt quicktime readline reflection samba sdl session speex spell spl sqlite ssl svg tcpd theora tiff truetype truetype-fonts type1-fonts unicode usb vorbis x264 xine xorg xpm xv xvid xvmc zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU video_cards_nv video_cards_nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Gentoo forum thread catalogging ppl with the problem A mix responce some have gone from ARCH to ~ARCH and it fixed but those that are already using ~ARCH for nividia-kernel are stuck (mix responce in running the NVIDIA-script directly) http://forums.gentoo.org/viewtopic-t-462098-highlight-.html
Right, I've also been experiencing this with the 2.6.17 kernel, and nvidia-kernel-1.0.8762. I've tried turning off confcache and userpriv in the hopes that they might be influencing the build process, but don't seem to be the problem... After a good hour or so of debugging, I've determined that the conftest.sh file can give different results on different merges, seemingly even though all the inputs are the same (which is what's really confusing me). In conftest.sh the only variables that seem to be used are defined within it (save for BUILD_PARAMS, but that doesn't seem to be set on any run of conftest, even though conftest gives different results). Conftest works by writing a little program, attempting to compile it, and checking whether the object file is created or not. Seemingly even though there is an error concerning "too few arguments to function x", sometimes conftest.sh can return a 0, and sometimes a 1 (this conftest.sh bit seems to get run twice during the course of an emerge). The primary two flags that seem to be causing problems are remap_pfn_range and pci_get_class. The differences between the two logs posted above, are the addition of the following definitions: -DNV_PCI_GET_CLASS_PRESENT -DNV_REMAP_PFN_RANGE_PRESENT and the removal of: -DNV_VM_INSERT_PAGE_PRESENT Which fits with the flaky conftest.sh tests giving different results for the same system. And that's as far as I've gotten. Anyone any ideas why conftest.sh should be returning different results from sequential emerges?
After checking around on the forums, this seems to be caused by ccache. Removing ccache from FEATURES allows nvidia-kernel to compile cleanly.
Yep, I'll buy that. Repeated recompiles with FEATURES="-ccache" do appear to give the same results each time, and do choose the correct -D flags. Perhaps this ebuild requires a RESTRICT="ccache" on it?
Well, this is strange. Changing RESTRICT="nostrip" to RESTRICT="nostrip ccache" doesn't seem to do anything. Even if I change it to just RESTRICT="ccache" I still get the build unresolved symbols, while if I remove ccache from FEATURES it compiles just fine!
I can confirm this as well. the ebuild needs to force off ccache... so damn frustrating.....
bleh, bugspam
Yup, disable ccache fixed it for me tnx
So would adding RESTRICT="ccache" to the nvidia-kernel (and now nvidia-drivers") ebuilds work? Can this be fixed quickly and easily?
(In reply to comment #15) > So would adding RESTRICT="ccache" to the nvidia-kernel (and now > nvidia-drivers") ebuilds work? Can this be fixed quickly and easily? > If restrict is supposed to work with ccache, it's broken. As I said in Comment #9 I tried this, and it doesn't do anything. For now you just need to use FEATURES="-ccache" :(
> As I said in Comment #9 I tried this, and it doesn't do anything. Erm, make that Comment #11 sorry
I can confirm that ccache caused the same problems for me as well.
ccache caused the same problem for me with a 2.6.17-rt8 kernel. The solution was the same, after removing ccache from Fetures, all was OK. Maybe at a good solution, if it is no mean to get portage to not use this cache, is to put an ewarn or einfo at the end of the ebuild to tell the user what to do. It is maybe not so clean, but it take me at least 2 hours before I found this bug report with the solution. Just to say, the problem is the same with x11-drivers/nvidia-drivers, and I try both the x86 and the ~x86 version of each.
(In reply to comment #19) > Maybe at a good solution, if it is no mean to get portage to not use this > cache, is to put an ewarn or einfo at the end of the ebuild to tell the user > what to do. I agree. It whould be very helpful for those that experience the problem. And if it's against good procedures to add a einfo/ewarn message about this, perhaps it could be considered a "special case" since: * problem hinders people from searching for help concerning the problem (no graphical interface) * it's _hard_ to understand how to solve or work aound the problem based on the error message * "rollback" of prevoiusly installed software version doesn't solve the problem Thanks finding out a way to solve the problem! (FEATURES="-ccache")
Hmmm, so? We can either stick an ewarn in pkg_setup(), like hasq ccache ${FEATURES} && ewarn "If this breaks, recompile without ccache" or we can do something really nasty in src_compile(), such as PATH="$(echo ":${PATH}:" | sed 's/:[^:]*ccache[^:]*:/:/;s/^://;s/:$//;')" RESTRICT="ccache" is not valid. Comments? (That said, I've never been able to reproduce the bug).
*** Bug 155300 has been marked as a duplicate of this bug. ***
Just ran into this issue. (In reply to comment #21) > Hmmm, so? We can either stick an ewarn in pkg_setup(), like > > hasq ccache ${FEATURES} && ewarn "If this breaks, recompile without ccache" > > or Simple solution, that just works (TM). Doing so would have saved me from many minutes of headache. > > RESTRICT="ccache" is not valid. Comments? (That said, I've never been able to > reproduce the bug). > I changed in the kernel config HIGHMEM support from "off" to "4GB", and after then wanted to recompile modules.
This doesn't seem to happen anymore with the newer versions of nvidia-drivers. However, it would be nice to have an ewarn in there letting people know if they get a lot of unknown symbols to rebuild with FEATURES="-ccache".
(In reply to comment #24) > This doesn't seem to happen anymore with the newer versions of nvidia-drivers. > > However, it would be nice to have an ewarn in there letting people know if they > get a lot of unknown symbols to rebuild with FEATURES="-ccache". Still happens with me for x11-drivers/nvidia-drivers-1.0.9755-r1, or do you mean the masked 100.14.09 with "newer"? Please implement the warning, I always forget about this when recompiling :-/
I compile everything with FEATURES="ccache" and have NEVER been able to reproduce this.
(In reply to comment #26) > I compile everything with FEATURES="ccache" and have NEVER been able to > reproduce this. > As I said above, it happens after you've changed something in the kernel config, in my case I've played around with the different "HIGHMEM support" options (off, 4GB, 64GB). This is affecting the kernel's internal structure and that's the reason why ccached compilation pieces won't work (at least in case of nvidia-drivers). To reproduce, just emerge nvidia-drivers with FEATURES="ccache" on your recent kernel, then change in your kernel config the "HIGHMEM support" to another value, build up the new kernel and afterwards re-emerge nvidia-drivers (still with FEATURES="ccache").
(In reply to comment #26) > I compile everything with FEATURES="ccache" and have NEVER been able to > reproduce this. > Thats not to say that the problem DOESNT exist... "it works for me" has NEVER been an acceptable response to a problem disabling ccache enabled me to emerge the nvidia-drivers, something that I could not do 100% of the time with ccache.
(In reply to comment #28) > (In reply to comment #26) > > I compile everything with FEATURES="ccache" and have NEVER been able to > > reproduce this. > > > > Thats not to say that the problem DOESNT exist... > "it works for me" has NEVER been an acceptable response to a problem Unless you give some way to reproduce the issue, it totally is. Since I am a volunteer on Gentoo, why should I run around attempting to fix a bug and take time away from my family because it's something you couldn't take the time and effort to do a little debugging on your own. If you can't take the time, then I can't take the time.
(In reply to comment #29) > (In reply to comment #28) > > (In reply to comment #26) > > > I compile everything with FEATURES="ccache" and have NEVER been able to > > > reproduce this. > > > > > > > Thats not to say that the problem DOESNT exist... > > "it works for me" has NEVER been an acceptable response to a problem > > Unless you give some way to reproduce the issue, it totally is. Since I am a > volunteer on Gentoo, why should I run around attempting to fix a bug and take > time away from my family because it's something you couldn't take the time and > effort to do a little debugging on your own. If you can't take the time, then I > can't take the time. > Ok, all that we're asking for is a 1 line change to an ebuild to provide an ewarn. That's it. In fact Jakub has already proposed this in comment #21. All that would be needed is to copy-and-paste. Yes, it's difficult to consistently reproduce this issue. But when it does happen disabling ccache FIXES it. Sure, we're only fixing the symptom, not the problem, but it works for a majority of the people.
(In reply to comment #29) > Unless you give some way to reproduce the issue, it totally is. I wouldn't know why, but it happens for me every time.
I want to confirm this bug report. I tried for about two days to emerge nvidia-drivers, and it always failed. I rebuilt a new kernel from scratch because I thought it was my configuration or something... and wasted a HUGE amount of time because of this. Removing 'ccache' from FEATURES temporarily after reading this bug report worked just fine. PLEASE put a warning message into the ebuild! Output of emerge --info: http://p173.de/gp/index.php?id=40e1f09b71
(In reply to comment #31) > (In reply to comment #29) > > Unless you give some way to reproduce the issue, it totally is. > > I wouldn't know why, but it happens for me every time. > Do you compile your kernels with straight gcc or with ccache wrapped gcc?
(In reply to comment #33) > Do you compile your kernels with straight gcc or with ccache wrapped gcc? Whatever "make" does, straight gcc, I think.
Any chance of getting a warning posted on the ebuild if it can't be turned off per-ebuild?
*** Bug 207384 has been marked as a duplicate of this bug. ***
I'm voting for the warning from #21 as well. Would have saved me a couple of hours debugging for nothing... Thanks.
This issue should be fixed in newer ebuilds since the ebuild will attempt to always disable ccache support when compiling nvidia-drivers.
(In reply to comment #38) I'm not sure what you mean by "newer ebuilds", but I'm still suffering it with nvidia-drivers-169.09-r1, which seems to postdate your comment.
(In reply to comment #39) > (In reply to comment #38) > I'm not sure what you mean by "newer ebuilds", but I'm still suffering it with > nvidia-drivers-169.09-r1, which seems to postdate your comment. > I still see the problem with nvidia-drivers-173.14.09. The ebuild seems to have a variable set that should switch ccache and even distcc off: # try to turn off distcc and ccache for people that have a problem with it export DISTCC_DISABLE=1 export CCACHE_DISABLE=1 But I still have to manually disable ccache to successfully compile nvidia-drivers.