Why does apt-get refuse to install cdefs.h (besides a symlink)?












1















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?










share|improve this question















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
















1















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?










share|improve this question















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














1












1








1








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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



















  • 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










1 Answer
1






active

oldest

votes


















0














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.






share|improve this answer























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    0














    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.






    share|improve this answer




























      0














      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.






      share|improve this answer


























        0












        0








        0







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 25 '16 at 16:55









        hydehyde

        5111516




        5111516






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Loup dans la culture

            How to solve the problem of ntp “Unable to contact time server” from KDE?

            Connection limited (no internet access)