我一直在尝试安装 32 位标头来满足依赖项较多的包64位今天晚上使用 Kali Linux，但我不太了解 Linux C 构建系统，无法调试这个问题。该文件是cdefs.h。据我了解，cdefs.h 仅出现在 32 位 Linux 中。
构建过程因为找不到 cdefs.h 而终止，所以我继续尝试寻找它。
root@kali:~# dpkg -S /usr/include/sys/cdefs.h
libc6-dev-i386: /usr/include/sys/cdefs.h
所以dpkg认为cdefs.h存在于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) ...
很好走吧？
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
哦，不，它不在那里。
root@kali:~# ls /usr/include/sys/cdefs.h
/usr/include/sys/cdefs.h
这是一个符号链接。
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
所有符号链接。
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
啊，所以我应该能够检查它们指向的位置，以确保它们状态良好。
root@kali:/usr/include/sys# cd ../x86_64-linux-gnu/
root@kali:/usr/include/x86_64-linux-gnu# ls
gnu
等等什么。所有内容都指向的 sys 文件夹在哪里？
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
它仍然不在这里。我在这里错过了一些非常愚蠢的事情吗？为什么 dkpg 公布的文件没有被安装？是什么阻碍了他们？它们应该存在于哪里？为什么 Windows 是 BSD 版本的 cdefs 唯一文件？
答案1
根据评论回答：
您问题中的命令 long 显示apt-get，然后locate紧随其后。
工作方式locate是，它有自己的文件系统中的文件数据库。该数据库使用命令更新updatedb，该命令通常由 执行cron，例如每天晚上。因此，如果您添加（或删除）文件，并想locate在之后立即使用，您需要updatedb自己运行（以 root 身份）。之后locate也会找到您的新文件。
对于所有在 Linux 上工作的程序员来说，了解这一点非常有用，因为在安装某些东西之后、或者在进行版本控制检查之后、或者只是进行构建之后需要查找文件是很常见的，并且使用find比locate.