On 08/03/2017 01:35 PM, Richard Shaw wrote:
On Thu, Aug 3, 2017 at 2:22 PM, Sherman Grunewagen <sugarwagon@xxxxxxx>
wrote:
<snip>
Not that anything useful/needed should be in /usr/local/include but what
are the permissions on it?
[root@new_pons ~]# ls -l /usr/local | fgrep include
drwxr-x--- 3 root root 4096 Aug 3 09:15 include
Ok, there is a problem but I don't know if it's THE problem. Everyone
should have read and execute permissions otherwise a normal user won't be
able to access the directory (and you should never build software as root!)
I've included all the directories as you should check the others as well:
$ ll /usr/local
total 40
drwxr-xr-x. 2 root root 4096 Aug 1 17:45 bin
drwxr-xr-x. 2 root root 4096 Feb 3 2016 etc
drwxr-xr-x. 2 root root 4096 Feb 3 2016 games
drwxr-xr-x. 6 root root 4096 Feb 18 07:27 include
drwxr-xr-x. 7 root root 4096 Feb 18 07:27 lib
drwxr-xr-x. 2 root root 4096 Feb 3 2016 lib64
drwxr-xr-x. 2 root root 4096 Feb 3 2016 libexec
drwxr-xr-x. 2 root root 4096 Feb 18 07:27 sbin
drwxr-xr-x. 12 root root 4096 Aug 1 17:45 share
drwxr-xr-x. 2 root root 4096 Feb 3 2016 src
A "chmod 0755 /usr/local/include" should fix that particular error, but
like I said, there's no telling if that's the underlying problem.
That was the problem! Nice catch. I'm clueless as to how previous
kmod-nvidia modules have built and run. And I don't understand
why, when running akmods as root, the "make" process is unable
to "see" inside /usr/local/include (nor why it needs to, but that's a
different question).
But turning on the "other" permissions did the trick!
I would not have guessed it.
-Sherman
P.S. I just checked and gcc and its kin were updated yesterday when this
problem began. Perhaps there's some new permissions demotion going on
in the compiler that wasn't there before.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
