Por que o apt-get se recusa a instalar o cdefs.h (além de um symlink)?

1

Eu tenho tentado instalar um cabeçalho de 32 bits para satisfazer um pacote separado por dependências em 64 bits Kali Linux esta noite, e eu não sei o sistema de compilação do Linux C bem o suficiente para depurar esse problema. O arquivo é cdefs.h. No meu entender, o cdefs.h ocorre apenas no Linux de 32 bits.

O processo de compilação morre porque não é possível encontrar o cdefs.h, então eu continuo tentando caçá-lo.

root@kali:~# dpkg -S /usr/include/sys/cdefs.h
libc6-dev-i386: /usr/include/sys/cdefs.h

Portanto, o dpkg acredita que o cdefs.h existe em 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) ...

Bom para dar certo?

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 não, não está lá.

root@kali:~# ls /usr/include/sys/cdefs.h
/usr/include/sys/cdefs.h

Este é um link simbólico.

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

Todos os links simbólicos.

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, então eu deveria ser capaz de verificar onde eles apontam para se certificar de que estão em boa forma.

root@kali:/usr/include/sys# cd ../x86_64-linux-gnu/
root@kali:/usr/include/x86_64-linux-gnu# ls
gnu

Espere o que. Onde está a pasta sys para onde tudo está apontando?

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

Ainda não está aqui. Eu estou sentindo falta de algo muito burro aqui? Por que os arquivos anunciados pelo dkpg não estão sendo instalados? O que poderia estar bloqueando eles? Onde eles deveriam existir? Por que o Windows é versões BSD do cdefs os únicos arquivos ao redor?

Ah, e eu sinto muito por estar fazendo uma pergunta sobre o Kali linux, eu percebo que todos concordaram mutuamente que está muito quebrado. Infelizmente, neste caso estou meio que usando isso. Estou preparado para receber os tomates para isso.

    
por baordog 24.08.2016 / 03:58

1 resposta

0

Responda com base nos comentários:

O comando que você tem em sua pergunta mostra apt-get e, em seguida, locate depois.

A maneira como o locate funciona é que ele possui seu próprio banco de dados para arquivos no sistema de arquivos. Este banco de dados é atualizado com o comando updatedb , que normalmente é executado por cron , por exemplo, todas as noites. Portanto, se você adicionar (ou remover) arquivos e quiser usar locate imediatamente depois, será necessário executar updatedb (como root). Depois disso, locate encontrará seus novos arquivos também.

Isso é bastante útil para todos os programadores que trabalham no Linux, já que é necessário localizar arquivos depois de instalar algo, ou depois de fazer uma verificação de controle de versão ou apenas compilar, e usar find é muito mais lento que locate .

    
por 25.08.2016 / 18:55