Why does apt-get refuse to install cdefs.h (besides a symlink)?
I've been trying to install a 32 bit header to satisfy a dependency ridden package in 64 bit Kali Linux this evening, and I don't know the Linux C build system well enough to debug this issue. The file is cdefs.h. It is my understanding that cdefs.h only occurs in 32 bit Linux.
The build process dies because it can't find cdefs.h, so I go on trying to hunt it down.
root@kali:~# dpkg -S /usr/include/sys/cdefs.h
libc6-dev-i386: /usr/include/sys/cdefs.h
So dpkg believes that cdefs.h exists in libc6-dev-i836
root@kali:~# apt-get install libc6-dev-i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6-dev-i386 is already the newest version.
The following packages were automatically installed and are no longer required:
lib32asan1 lib32atomic1 lib32cilkrts5 lib32gcc1 lib32gomp1 lib32itm1 lib32quadmath0 lib32stdc++6
lib32ubsan0 libc6-amd64:i386 libltdl-dev xinit
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up libc6-amd64 (2.19-18+deb8u3) ...
Processing triggers for libc-bin (2.19-18+deb8u3) ...
Good to go right?
root@kali:~# locate cdefs.h
/usr/i686-w64-mingw32/include/sys/cdefs.h
/usr/include/bsd/sys/cdefs.h
/usr/share/mingw-w64/include/sys/cdefs.h
Oh no it's not there.
root@kali:~# ls /usr/include/sys/cdefs.h
/usr/include/sys/cdefs.h
This is a symlink.
root@kali:~# cd /usr/include/sys/
root@kali:/usr/include/sys# ls
acct.h fcntl.h klog.h procfs.h sendfile.h swap.h timex.h utsname.h
auxv.h file.h mman.h profil.h shm.h syscall.h ttychars.h vfs.h
bitypes.h fsuid.h mount.h ptrace.h signalfd.h sysctl.h ttydefaults.h vlimit.h
cdefs.h gmon.h msg.h queue.h signal.h sysinfo.h types.h vm86.h
debugreg.h gmon_out.h mtio.h quota.h socket.h syslog.h ucontext.h vt.h
dir.h inotify.h param.h raw.h socketvar.h sysmacros.h uio.h vtimes.h
elf.h ioctl.h pci.h reboot.h soundcard.h termios.h ultrasound.h wait.h
epoll.h io.h perm.h reg.h statfs.h timeb.h un.h xattr.h
errno.h ipc.h personality.h resource.h stat.h time.h unistd.h
eventfd.h kdaemon.h poll.h select.h statvfs.h timerfd.h user.h
fanotify.h kd.h prctl.h sem.h stropts.h times.h ustat.h
All symlinks.
root@kali:/usr/include/sys# ls -la
total 32
drwxr-xr-x 2 root root 12288 Aug 23 21:18 .
drwxr-xr-x 76 root root 20480 Aug 23 21:34 ..
lrwxrwxrwx 1 root root 30 Feb 11 2016 acct.h -> ../x86_64-linux-gnu/sys/acct.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 auxv.h -> ../x86_64-linux-gnu/sys/auxv.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 bitypes.h -> ../x86_64-linux-gnu/sys/bitypes.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 cdefs.h -> ../x86_64-linux-gnu/sys/cdefs.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 debugreg.h -> ../x86_64-linux-gnu/sys/debugreg.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 dir.h -> ../x86_64-linux-gnu/sys/dir.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 elf.h -> ../x86_64-linux-gnu/sys/elf.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 epoll.h -> ../x86_64-linux-gnu/sys/epoll.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 errno.h -> ../x86_64-linux-gnu/sys/errno.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 eventfd.h -> ../x86_64-linux-gnu/sys/eventfd.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 fanotify.h -> ../x86_64-linux-gnu/sys/fanotify.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 fcntl.h -> ../x86_64-linux-gnu/sys/fcntl.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 file.h -> ../x86_64-linux-gnu/sys/file.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 fsuid.h -> ../x86_64-linux-gnu/sys/fsuid.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 gmon.h -> ../x86_64-linux-gnu/sys/gmon.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 gmon_out.h -> ../x86_64-linux-gnu/sys/gmon_out.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 inotify.h -> ../x86_64-linux-gnu/sys/inotify.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 ioctl.h -> ../x86_64-linux-gnu/sys/ioctl.h
lrwxrwxrwx 1 root root 28 Feb 11 2016 io.h -> ../x86_64-linux-gnu/sys/io.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 ipc.h -> ../x86_64-linux-gnu/sys/ipc.h
Ah so I should just be able to check to where they point to make sure they are in good shape.
root@kali:/usr/include/sys# cd ../x86_64-linux-gnu/
root@kali:/usr/include/x86_64-linux-gnu# ls
gnu
Wait what. Where's the sys folder everything is pointing to?
root@kali:/usr/include/x86_64-linux-gnu# locate vfs.h
/usr/include/glib-2.0/gio/gvfs.h
/usr/src/linux-headers-4.0.0-kali1-common/include/linux/vfs.h
root@kali:/usr/include/x86_64-linux-gnu# locate cdefs.h
/usr/i686-w64-mingw32/include/sys/cdefs.h
/usr/include/bsd/sys/cdefs.h
/usr/share/mingw-w64/include/sys/cdefs.h
It's still not here. Am I missing something very dumb here?
Why aren't the files advertised by dkpg being installed?
What could be blocking them?
Where should they exist?
Why are the Windows are BSD versions of cdefs the only files around?
apt dpkg kali-linux
migrated from stackoverflow.com Sep 7 '16 at 20:20
This question came from our site for professional and enthusiast programmers.
add a comment |
I've been trying to install a 32 bit header to satisfy a dependency ridden package in 64 bit Kali Linux this evening, and I don't know the Linux C build system well enough to debug this issue. The file is cdefs.h. It is my understanding that cdefs.h only occurs in 32 bit Linux.
The build process dies because it can't find cdefs.h, so I go on trying to hunt it down.
root@kali:~# dpkg -S /usr/include/sys/cdefs.h
libc6-dev-i386: /usr/include/sys/cdefs.h
So dpkg believes that cdefs.h exists in libc6-dev-i836
root@kali:~# apt-get install libc6-dev-i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6-dev-i386 is already the newest version.
The following packages were automatically installed and are no longer required:
lib32asan1 lib32atomic1 lib32cilkrts5 lib32gcc1 lib32gomp1 lib32itm1 lib32quadmath0 lib32stdc++6
lib32ubsan0 libc6-amd64:i386 libltdl-dev xinit
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up libc6-amd64 (2.19-18+deb8u3) ...
Processing triggers for libc-bin (2.19-18+deb8u3) ...
Good to go right?
root@kali:~# locate cdefs.h
/usr/i686-w64-mingw32/include/sys/cdefs.h
/usr/include/bsd/sys/cdefs.h
/usr/share/mingw-w64/include/sys/cdefs.h
Oh no it's not there.
root@kali:~# ls /usr/include/sys/cdefs.h
/usr/include/sys/cdefs.h
This is a symlink.
root@kali:~# cd /usr/include/sys/
root@kali:/usr/include/sys# ls
acct.h fcntl.h klog.h procfs.h sendfile.h swap.h timex.h utsname.h
auxv.h file.h mman.h profil.h shm.h syscall.h ttychars.h vfs.h
bitypes.h fsuid.h mount.h ptrace.h signalfd.h sysctl.h ttydefaults.h vlimit.h
cdefs.h gmon.h msg.h queue.h signal.h sysinfo.h types.h vm86.h
debugreg.h gmon_out.h mtio.h quota.h socket.h syslog.h ucontext.h vt.h
dir.h inotify.h param.h raw.h socketvar.h sysmacros.h uio.h vtimes.h
elf.h ioctl.h pci.h reboot.h soundcard.h termios.h ultrasound.h wait.h
epoll.h io.h perm.h reg.h statfs.h timeb.h un.h xattr.h
errno.h ipc.h personality.h resource.h stat.h time.h unistd.h
eventfd.h kdaemon.h poll.h select.h statvfs.h timerfd.h user.h
fanotify.h kd.h prctl.h sem.h stropts.h times.h ustat.h
All symlinks.
root@kali:/usr/include/sys# ls -la
total 32
drwxr-xr-x 2 root root 12288 Aug 23 21:18 .
drwxr-xr-x 76 root root 20480 Aug 23 21:34 ..
lrwxrwxrwx 1 root root 30 Feb 11 2016 acct.h -> ../x86_64-linux-gnu/sys/acct.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 auxv.h -> ../x86_64-linux-gnu/sys/auxv.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 bitypes.h -> ../x86_64-linux-gnu/sys/bitypes.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 cdefs.h -> ../x86_64-linux-gnu/sys/cdefs.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 debugreg.h -> ../x86_64-linux-gnu/sys/debugreg.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 dir.h -> ../x86_64-linux-gnu/sys/dir.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 elf.h -> ../x86_64-linux-gnu/sys/elf.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 epoll.h -> ../x86_64-linux-gnu/sys/epoll.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 errno.h -> ../x86_64-linux-gnu/sys/errno.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 eventfd.h -> ../x86_64-linux-gnu/sys/eventfd.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 fanotify.h -> ../x86_64-linux-gnu/sys/fanotify.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 fcntl.h -> ../x86_64-linux-gnu/sys/fcntl.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 file.h -> ../x86_64-linux-gnu/sys/file.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 fsuid.h -> ../x86_64-linux-gnu/sys/fsuid.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 gmon.h -> ../x86_64-linux-gnu/sys/gmon.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 gmon_out.h -> ../x86_64-linux-gnu/sys/gmon_out.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 inotify.h -> ../x86_64-linux-gnu/sys/inotify.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 ioctl.h -> ../x86_64-linux-gnu/sys/ioctl.h
lrwxrwxrwx 1 root root 28 Feb 11 2016 io.h -> ../x86_64-linux-gnu/sys/io.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 ipc.h -> ../x86_64-linux-gnu/sys/ipc.h
Ah so I should just be able to check to where they point to make sure they are in good shape.
root@kali:/usr/include/sys# cd ../x86_64-linux-gnu/
root@kali:/usr/include/x86_64-linux-gnu# ls
gnu
Wait what. Where's the sys folder everything is pointing to?
root@kali:/usr/include/x86_64-linux-gnu# locate vfs.h
/usr/include/glib-2.0/gio/gvfs.h
/usr/src/linux-headers-4.0.0-kali1-common/include/linux/vfs.h
root@kali:/usr/include/x86_64-linux-gnu# locate cdefs.h
/usr/i686-w64-mingw32/include/sys/cdefs.h
/usr/include/bsd/sys/cdefs.h
/usr/share/mingw-w64/include/sys/cdefs.h
It's still not here. Am I missing something very dumb here?
Why aren't the files advertised by dkpg being installed?
What could be blocking them?
Where should they exist?
Why are the Windows are BSD versions of cdefs the only files around?
apt dpkg kali-linux
migrated from stackoverflow.com Sep 7 '16 at 20:20
This question came from our site for professional and enthusiast programmers.
You need to run updatedb command to update locate database. Also, use dpkg -L to list files in a package.
– hyde
Aug 24 '16 at 5:01
Just updatedb in the terminal? Did nothing whatsoever for me, returned instantly so it's clearly not downloading anything.
– baordog
Aug 24 '16 at 13:05
If you have SSD, updatedb can be very fast. It printa nothing on success, but locate only finds files which existed when updatedb was last run.
– hyde
Aug 24 '16 at 14:03
So updatedb appears to have fixed the issue. One other problem I was having was that I installed the i386 libs rather than the amd64 libs.
– baordog
Aug 24 '16 at 14:04
"I realize everyone has mutually agreed it's very broken." :) I don't really think that Kali is broken, but it's a specialised distro and not particularly newbie-friendly.
– Fred Barclay
Aug 24 '16 at 23:16
add a comment |
I've been trying to install a 32 bit header to satisfy a dependency ridden package in 64 bit Kali Linux this evening, and I don't know the Linux C build system well enough to debug this issue. The file is cdefs.h. It is my understanding that cdefs.h only occurs in 32 bit Linux.
The build process dies because it can't find cdefs.h, so I go on trying to hunt it down.
root@kali:~# dpkg -S /usr/include/sys/cdefs.h
libc6-dev-i386: /usr/include/sys/cdefs.h
So dpkg believes that cdefs.h exists in libc6-dev-i836
root@kali:~# apt-get install libc6-dev-i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6-dev-i386 is already the newest version.
The following packages were automatically installed and are no longer required:
lib32asan1 lib32atomic1 lib32cilkrts5 lib32gcc1 lib32gomp1 lib32itm1 lib32quadmath0 lib32stdc++6
lib32ubsan0 libc6-amd64:i386 libltdl-dev xinit
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up libc6-amd64 (2.19-18+deb8u3) ...
Processing triggers for libc-bin (2.19-18+deb8u3) ...
Good to go right?
root@kali:~# locate cdefs.h
/usr/i686-w64-mingw32/include/sys/cdefs.h
/usr/include/bsd/sys/cdefs.h
/usr/share/mingw-w64/include/sys/cdefs.h
Oh no it's not there.
root@kali:~# ls /usr/include/sys/cdefs.h
/usr/include/sys/cdefs.h
This is a symlink.
root@kali:~# cd /usr/include/sys/
root@kali:/usr/include/sys# ls
acct.h fcntl.h klog.h procfs.h sendfile.h swap.h timex.h utsname.h
auxv.h file.h mman.h profil.h shm.h syscall.h ttychars.h vfs.h
bitypes.h fsuid.h mount.h ptrace.h signalfd.h sysctl.h ttydefaults.h vlimit.h
cdefs.h gmon.h msg.h queue.h signal.h sysinfo.h types.h vm86.h
debugreg.h gmon_out.h mtio.h quota.h socket.h syslog.h ucontext.h vt.h
dir.h inotify.h param.h raw.h socketvar.h sysmacros.h uio.h vtimes.h
elf.h ioctl.h pci.h reboot.h soundcard.h termios.h ultrasound.h wait.h
epoll.h io.h perm.h reg.h statfs.h timeb.h un.h xattr.h
errno.h ipc.h personality.h resource.h stat.h time.h unistd.h
eventfd.h kdaemon.h poll.h select.h statvfs.h timerfd.h user.h
fanotify.h kd.h prctl.h sem.h stropts.h times.h ustat.h
All symlinks.
root@kali:/usr/include/sys# ls -la
total 32
drwxr-xr-x 2 root root 12288 Aug 23 21:18 .
drwxr-xr-x 76 root root 20480 Aug 23 21:34 ..
lrwxrwxrwx 1 root root 30 Feb 11 2016 acct.h -> ../x86_64-linux-gnu/sys/acct.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 auxv.h -> ../x86_64-linux-gnu/sys/auxv.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 bitypes.h -> ../x86_64-linux-gnu/sys/bitypes.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 cdefs.h -> ../x86_64-linux-gnu/sys/cdefs.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 debugreg.h -> ../x86_64-linux-gnu/sys/debugreg.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 dir.h -> ../x86_64-linux-gnu/sys/dir.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 elf.h -> ../x86_64-linux-gnu/sys/elf.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 epoll.h -> ../x86_64-linux-gnu/sys/epoll.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 errno.h -> ../x86_64-linux-gnu/sys/errno.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 eventfd.h -> ../x86_64-linux-gnu/sys/eventfd.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 fanotify.h -> ../x86_64-linux-gnu/sys/fanotify.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 fcntl.h -> ../x86_64-linux-gnu/sys/fcntl.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 file.h -> ../x86_64-linux-gnu/sys/file.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 fsuid.h -> ../x86_64-linux-gnu/sys/fsuid.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 gmon.h -> ../x86_64-linux-gnu/sys/gmon.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 gmon_out.h -> ../x86_64-linux-gnu/sys/gmon_out.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 inotify.h -> ../x86_64-linux-gnu/sys/inotify.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 ioctl.h -> ../x86_64-linux-gnu/sys/ioctl.h
lrwxrwxrwx 1 root root 28 Feb 11 2016 io.h -> ../x86_64-linux-gnu/sys/io.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 ipc.h -> ../x86_64-linux-gnu/sys/ipc.h
Ah so I should just be able to check to where they point to make sure they are in good shape.
root@kali:/usr/include/sys# cd ../x86_64-linux-gnu/
root@kali:/usr/include/x86_64-linux-gnu# ls
gnu
Wait what. Where's the sys folder everything is pointing to?
root@kali:/usr/include/x86_64-linux-gnu# locate vfs.h
/usr/include/glib-2.0/gio/gvfs.h
/usr/src/linux-headers-4.0.0-kali1-common/include/linux/vfs.h
root@kali:/usr/include/x86_64-linux-gnu# locate cdefs.h
/usr/i686-w64-mingw32/include/sys/cdefs.h
/usr/include/bsd/sys/cdefs.h
/usr/share/mingw-w64/include/sys/cdefs.h
It's still not here. Am I missing something very dumb here?
Why aren't the files advertised by dkpg being installed?
What could be blocking them?
Where should they exist?
Why are the Windows are BSD versions of cdefs the only files around?
apt dpkg kali-linux
I've been trying to install a 32 bit header to satisfy a dependency ridden package in 64 bit Kali Linux this evening, and I don't know the Linux C build system well enough to debug this issue. The file is cdefs.h. It is my understanding that cdefs.h only occurs in 32 bit Linux.
The build process dies because it can't find cdefs.h, so I go on trying to hunt it down.
root@kali:~# dpkg -S /usr/include/sys/cdefs.h
libc6-dev-i386: /usr/include/sys/cdefs.h
So dpkg believes that cdefs.h exists in libc6-dev-i836
root@kali:~# apt-get install libc6-dev-i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6-dev-i386 is already the newest version.
The following packages were automatically installed and are no longer required:
lib32asan1 lib32atomic1 lib32cilkrts5 lib32gcc1 lib32gomp1 lib32itm1 lib32quadmath0 lib32stdc++6
lib32ubsan0 libc6-amd64:i386 libltdl-dev xinit
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up libc6-amd64 (2.19-18+deb8u3) ...
Processing triggers for libc-bin (2.19-18+deb8u3) ...
Good to go right?
root@kali:~# locate cdefs.h
/usr/i686-w64-mingw32/include/sys/cdefs.h
/usr/include/bsd/sys/cdefs.h
/usr/share/mingw-w64/include/sys/cdefs.h
Oh no it's not there.
root@kali:~# ls /usr/include/sys/cdefs.h
/usr/include/sys/cdefs.h
This is a symlink.
root@kali:~# cd /usr/include/sys/
root@kali:/usr/include/sys# ls
acct.h fcntl.h klog.h procfs.h sendfile.h swap.h timex.h utsname.h
auxv.h file.h mman.h profil.h shm.h syscall.h ttychars.h vfs.h
bitypes.h fsuid.h mount.h ptrace.h signalfd.h sysctl.h ttydefaults.h vlimit.h
cdefs.h gmon.h msg.h queue.h signal.h sysinfo.h types.h vm86.h
debugreg.h gmon_out.h mtio.h quota.h socket.h syslog.h ucontext.h vt.h
dir.h inotify.h param.h raw.h socketvar.h sysmacros.h uio.h vtimes.h
elf.h ioctl.h pci.h reboot.h soundcard.h termios.h ultrasound.h wait.h
epoll.h io.h perm.h reg.h statfs.h timeb.h un.h xattr.h
errno.h ipc.h personality.h resource.h stat.h time.h unistd.h
eventfd.h kdaemon.h poll.h select.h statvfs.h timerfd.h user.h
fanotify.h kd.h prctl.h sem.h stropts.h times.h ustat.h
All symlinks.
root@kali:/usr/include/sys# ls -la
total 32
drwxr-xr-x 2 root root 12288 Aug 23 21:18 .
drwxr-xr-x 76 root root 20480 Aug 23 21:34 ..
lrwxrwxrwx 1 root root 30 Feb 11 2016 acct.h -> ../x86_64-linux-gnu/sys/acct.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 auxv.h -> ../x86_64-linux-gnu/sys/auxv.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 bitypes.h -> ../x86_64-linux-gnu/sys/bitypes.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 cdefs.h -> ../x86_64-linux-gnu/sys/cdefs.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 debugreg.h -> ../x86_64-linux-gnu/sys/debugreg.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 dir.h -> ../x86_64-linux-gnu/sys/dir.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 elf.h -> ../x86_64-linux-gnu/sys/elf.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 epoll.h -> ../x86_64-linux-gnu/sys/epoll.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 errno.h -> ../x86_64-linux-gnu/sys/errno.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 eventfd.h -> ../x86_64-linux-gnu/sys/eventfd.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 fanotify.h -> ../x86_64-linux-gnu/sys/fanotify.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 fcntl.h -> ../x86_64-linux-gnu/sys/fcntl.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 file.h -> ../x86_64-linux-gnu/sys/file.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 fsuid.h -> ../x86_64-linux-gnu/sys/fsuid.h
lrwxrwxrwx 1 root root 30 Feb 11 2016 gmon.h -> ../x86_64-linux-gnu/sys/gmon.h
lrwxrwxrwx 1 root root 34 Feb 11 2016 gmon_out.h -> ../x86_64-linux-gnu/sys/gmon_out.h
lrwxrwxrwx 1 root root 33 Feb 11 2016 inotify.h -> ../x86_64-linux-gnu/sys/inotify.h
lrwxrwxrwx 1 root root 31 Feb 11 2016 ioctl.h -> ../x86_64-linux-gnu/sys/ioctl.h
lrwxrwxrwx 1 root root 28 Feb 11 2016 io.h -> ../x86_64-linux-gnu/sys/io.h
lrwxrwxrwx 1 root root 29 Feb 11 2016 ipc.h -> ../x86_64-linux-gnu/sys/ipc.h
Ah so I should just be able to check to where they point to make sure they are in good shape.
root@kali:/usr/include/sys# cd ../x86_64-linux-gnu/
root@kali:/usr/include/x86_64-linux-gnu# ls
gnu
Wait what. Where's the sys folder everything is pointing to?
root@kali:/usr/include/x86_64-linux-gnu# locate vfs.h
/usr/include/glib-2.0/gio/gvfs.h
/usr/src/linux-headers-4.0.0-kali1-common/include/linux/vfs.h
root@kali:/usr/include/x86_64-linux-gnu# locate cdefs.h
/usr/i686-w64-mingw32/include/sys/cdefs.h
/usr/include/bsd/sys/cdefs.h
/usr/share/mingw-w64/include/sys/cdefs.h
It's still not here. Am I missing something very dumb here?
Why aren't the files advertised by dkpg being installed?
What could be blocking them?
Where should they exist?
Why are the Windows are BSD versions of cdefs the only files around?
apt dpkg kali-linux
apt dpkg kali-linux
edited 1 hour ago
Rui F Ribeiro
39.6k1479132
39.6k1479132
asked Aug 24 '16 at 1:58
baordogbaordog
15417
15417
migrated from stackoverflow.com Sep 7 '16 at 20:20
This question came from our site for professional and enthusiast programmers.
migrated from stackoverflow.com Sep 7 '16 at 20:20
This question came from our site for professional and enthusiast programmers.
You need to run updatedb command to update locate database. Also, use dpkg -L to list files in a package.
– hyde
Aug 24 '16 at 5:01
Just updatedb in the terminal? Did nothing whatsoever for me, returned instantly so it's clearly not downloading anything.
– baordog
Aug 24 '16 at 13:05
If you have SSD, updatedb can be very fast. It printa nothing on success, but locate only finds files which existed when updatedb was last run.
– hyde
Aug 24 '16 at 14:03
So updatedb appears to have fixed the issue. One other problem I was having was that I installed the i386 libs rather than the amd64 libs.
– baordog
Aug 24 '16 at 14:04
"I realize everyone has mutually agreed it's very broken." :) I don't really think that Kali is broken, but it's a specialised distro and not particularly newbie-friendly.
– Fred Barclay
Aug 24 '16 at 23:16
add a comment |
You need to run updatedb command to update locate database. Also, use dpkg -L to list files in a package.
– hyde
Aug 24 '16 at 5:01
Just updatedb in the terminal? Did nothing whatsoever for me, returned instantly so it's clearly not downloading anything.
– baordog
Aug 24 '16 at 13:05
If you have SSD, updatedb can be very fast. It printa nothing on success, but locate only finds files which existed when updatedb was last run.
– hyde
Aug 24 '16 at 14:03
So updatedb appears to have fixed the issue. One other problem I was having was that I installed the i386 libs rather than the amd64 libs.
– baordog
Aug 24 '16 at 14:04
"I realize everyone has mutually agreed it's very broken." :) I don't really think that Kali is broken, but it's a specialised distro and not particularly newbie-friendly.
– Fred Barclay
Aug 24 '16 at 23:16
You need to run updatedb command to update locate database. Also, use dpkg -L to list files in a package.
– hyde
Aug 24 '16 at 5:01
You need to run updatedb command to update locate database. Also, use dpkg -L to list files in a package.
– hyde
Aug 24 '16 at 5:01
Just updatedb in the terminal? Did nothing whatsoever for me, returned instantly so it's clearly not downloading anything.
– baordog
Aug 24 '16 at 13:05
Just updatedb in the terminal? Did nothing whatsoever for me, returned instantly so it's clearly not downloading anything.
– baordog
Aug 24 '16 at 13:05
If you have SSD, updatedb can be very fast. It printa nothing on success, but locate only finds files which existed when updatedb was last run.
– hyde
Aug 24 '16 at 14:03
If you have SSD, updatedb can be very fast. It printa nothing on success, but locate only finds files which existed when updatedb was last run.
– hyde
Aug 24 '16 at 14:03
So updatedb appears to have fixed the issue. One other problem I was having was that I installed the i386 libs rather than the amd64 libs.
– baordog
Aug 24 '16 at 14:04
So updatedb appears to have fixed the issue. One other problem I was having was that I installed the i386 libs rather than the amd64 libs.
– baordog
Aug 24 '16 at 14:04
"I realize everyone has mutually agreed it's very broken." :) I don't really think that Kali is broken, but it's a specialised distro and not particularly newbie-friendly.
– Fred Barclay
Aug 24 '16 at 23:16
"I realize everyone has mutually agreed it's very broken." :) I don't really think that Kali is broken, but it's a specialised distro and not particularly newbie-friendly.
– Fred Barclay
Aug 24 '16 at 23:16
add a comment |
1 Answer
1
active
oldest
votes
Answer based on comments:
The command long you have in your question shows apt-get
, and then locate
right after.
The way locate
works is, it has it's own database for files in the file system. This database is updated with updatedb
command, which is normally executed by cron
, for example every night. So if you add (or remove) files, and want to use locate
immediately after, you need to run updatedb
(as root) yourself. After that locate
will find your new files too.
This is rather useful to know for all programmers working on Linux, since needing to find files after installing something, or after doing a version control checkout, or just doing a build, is quite common, and using find
is much slower than locate
.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f308490%2fwhy-does-apt-get-refuse-to-install-cdefs-h-besides-a-symlink%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Answer based on comments:
The command long you have in your question shows apt-get
, and then locate
right after.
The way locate
works is, it has it's own database for files in the file system. This database is updated with updatedb
command, which is normally executed by cron
, for example every night. So if you add (or remove) files, and want to use locate
immediately after, you need to run updatedb
(as root) yourself. After that locate
will find your new files too.
This is rather useful to know for all programmers working on Linux, since needing to find files after installing something, or after doing a version control checkout, or just doing a build, is quite common, and using find
is much slower than locate
.
add a comment |
Answer based on comments:
The command long you have in your question shows apt-get
, and then locate
right after.
The way locate
works is, it has it's own database for files in the file system. This database is updated with updatedb
command, which is normally executed by cron
, for example every night. So if you add (or remove) files, and want to use locate
immediately after, you need to run updatedb
(as root) yourself. After that locate
will find your new files too.
This is rather useful to know for all programmers working on Linux, since needing to find files after installing something, or after doing a version control checkout, or just doing a build, is quite common, and using find
is much slower than locate
.
add a comment |
Answer based on comments:
The command long you have in your question shows apt-get
, and then locate
right after.
The way locate
works is, it has it's own database for files in the file system. This database is updated with updatedb
command, which is normally executed by cron
, for example every night. So if you add (or remove) files, and want to use locate
immediately after, you need to run updatedb
(as root) yourself. After that locate
will find your new files too.
This is rather useful to know for all programmers working on Linux, since needing to find files after installing something, or after doing a version control checkout, or just doing a build, is quite common, and using find
is much slower than locate
.
Answer based on comments:
The command long you have in your question shows apt-get
, and then locate
right after.
The way locate
works is, it has it's own database for files in the file system. This database is updated with updatedb
command, which is normally executed by cron
, for example every night. So if you add (or remove) files, and want to use locate
immediately after, you need to run updatedb
(as root) yourself. After that locate
will find your new files too.
This is rather useful to know for all programmers working on Linux, since needing to find files after installing something, or after doing a version control checkout, or just doing a build, is quite common, and using find
is much slower than locate
.
answered Aug 25 '16 at 16:55
hydehyde
5111516
5111516
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f308490%2fwhy-does-apt-get-refuse-to-install-cdefs-h-besides-a-symlink%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You need to run updatedb command to update locate database. Also, use dpkg -L to list files in a package.
– hyde
Aug 24 '16 at 5:01
Just updatedb in the terminal? Did nothing whatsoever for me, returned instantly so it's clearly not downloading anything.
– baordog
Aug 24 '16 at 13:05
If you have SSD, updatedb can be very fast. It printa nothing on success, but locate only finds files which existed when updatedb was last run.
– hyde
Aug 24 '16 at 14:03
So updatedb appears to have fixed the issue. One other problem I was having was that I installed the i386 libs rather than the amd64 libs.
– baordog
Aug 24 '16 at 14:04
"I realize everyone has mutually agreed it's very broken." :) I don't really think that Kali is broken, but it's a specialised distro and not particularly newbie-friendly.
– Fred Barclay
Aug 24 '16 at 23:16