2015-07-13 10 views
5

Próbuję zainstalować jakiś nowy pakiet oprogramowania pod openwrt za pomocą opkg, a instalacja zakończyła się sukcesem, i możemy zobaczyć plik binarny istnieje naprawdę w katalogu/usr/bin, a ja trduje się sprawdzeniem Lld, ale okazuje się taki sam. poniżej:Plik ELF istnieje w/usr/bin, ale okazuje się, że "-ash: file: not found"

[email protected] /usr/bin [#]# opkg files cfdisk 
Package cfdisk (2.25.2-4) is installed on root and has the following files: 
/usr/sbin/cfdisk 
[email protected] /usr/bin [#]# ls /usr/sbin/ 
adjtimex    arping     ethtool     iptables-save   mkfs.ext3    pppd     telnetd 
airbase-ng    besside-ng    fdisk     iw      mkfs.ext4    rate.awk    uhttpd 
aireplay-ng    brctl     hostapd     iwconfig    modinfo     rmmod     wpa_supplicant 
airmon-ng    cfdisk     insmod     iwlist     modprobe    samba_multicall   wpad 
airmon-zc    chroot     ip6tables    iwpriv     nmbd     smbd     xtables-multi 
airodump-ng    crond     ip6tables-restore  lsmod     ntpclient    smbpasswd 
airodump-ng-oui-update dnsmasq     ip6tables-save   miniupnpd    ntpd     swapoff 
airserv-ng    dropbear    iptables    mke2fs     odhcp6c     swapon 
airtun-ng    e2fsck     iptables-restore  mkfs.ext2    pdnsd     tc 
[email protected] /usr/bin [#]# cfdisk 
-ash: cfdisk: not found 
[email protected] /usr/bin [#]# ./cfdisk 
-ash: ./cfdisk: not found 
[email protected] /usr/bin [#]# ldd cfdisk 
-ash: cfdisk: not found 
[email protected] /usr/bin [#]# ldd id 
     libcrypt.so.0 => /lib/libcrypt.so.0 (0x77898000) 
     libm.so.0 => /lib/libm.so.0 (0x77872000) 
     libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7784e000) 
     libc.so.0 => /lib/libc.so.0 (0x777e2000) 
     ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x778bc000) 
[email protected] /usr/bin [#]# export 
export HOME='/root' 
export LOGNAME='root' 
export OLDPWD='/usr' 
export PATH='/usr/bin:/usr/sbin:/bin:/sbin' 
export PS1='\[\033[35;1m\]\u\[\033[0m\]@\[\033[31;1m\]\h \[\033[32;1m\]$PWD\[\033[0m\] [\[\033[35m\]\#\[\033[0m\]]\[\033[31m\]\$\[\033[0m\] ' 
export PWD='/usr/bin' 
export SHELL='/bin/ash' 
export SHLVL='1' 
export SSH_CONNECTION='192.168.1.152 29105 192.168.1.1 22' 
export SSH_TTY='/dev/pts/0' 
export TERM='xterm' 
export USER='root' 
[email protected] /usr/bin [#]# 

dziękuję.

+1

Twój plik binarny cfdisk jest prawdopodobnie powiązany z dynamicznym linkerem, który nie istnieje (tzn. Czymś innym niż ld-uClibc.so.0) Uruchom 'readelf -a' na swoim binarnym, poszukaj" interpretera programów " – nos

+0

thanks @ nos, readelf nie został jeszcze zainstalowany .. czy powinienem skopiować ten plik do mojego systemu Ubuntu, który ma readelf, a następnie go sprawdzić? i myślę, że to prawdopodobnie spowodowane przez wersję linuksową. przez sposób, "ld-uClibc.so.0 "jest z" id "jako polecenie" lld id "tylko dla porównania z' ldd cfdisk'. – coder

+0

Oczywiście, uruchom readelf na binariach, gdziekolwiek chcesz. Mówię, że skoro 'id id" pokazuje 'ld-uClibc.so.0', to ta konkretna biblioteka istnieje. a twój cfdisk prawdopodobnie tego nie używa, ale inny dynamiczny linker, który nie istnieje na twoim komputerze. Być może z powodu kompilacji cfdisk z inną wersją uClibc lub innej biblioteki C. – nos

Odpowiedz

1

Jak wspomniano w komentarzach do pytania @nos, może się to zdarzyć, jeśli plik binarny jest połączony z biblioteką libc, która nie istnieje na Twoim urządzeniu.

np. To jest wynik, który otrzymuję, gdy próbuję uruchomić plik binarny, który został zbudowany z niewłaściwą biblioteką libc (pamiętaj, że podaję pełną ścieżkę /usr/bin/ldd, ponieważ bez tego z jakiegoś powodu otrzymywałam ten sam błąd "nie znaleziono", który zauważyłeś w swoim pytaniu).

[email protected]:~# /usr/bin/ldd badbin 
ldd: can't open cache '/etc/ld.so.cache' 
checking sub-depends for '/usr/lib/libusb-1.0.so.0' 
checking sub-depends for '/lib/libgcc_s.so.1' 
checking sub-depends for 'not found' 
    libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0x00000000) 
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00000000) 
    libc.so => not found (0x00000000) 
    not a dynamic executable 

Dla mnie problemem było to, że budowałem swój pakiet za pomocą niewłaściwego toolchaina. Przyjąłem, że repozytorium git://git.openwrt.org/openwrt.git było dla Chaosa Calmera (obecne wydanie w momencie pisania). Ale oczywiście repo jest gałęzią rozwojową (svn trunk). Musiałem zamiast tego użyć git://git.openwrt.org/15.05/openwrt.git.

Możesz potwierdzić, z której biblioteki chcesz skorzystać, sprawdzając nazwę katalogu narzędziowego staging_dir. Wersja libc jest ostatnim składnikiem nazwy (np. toolchain-mips_34kc+dsp_gcc-4.8-linaro_uClibc-0.9.33.2 używa uClibc-0.9.33.2).

Należy porównać tę wersję z wersją biblioteki libc, która jest obecna na routerze, sprawdzając, które łącza /lib/libc.so* prowadzą do routera (uruchom ls -l /lib/libc.so*). Jeśli potrzebujesz zmienić wersję libc używaną przez twój toolchain, to wykonaj make menuconfig w OpenWRT buildroot i ustaw wersję libc w Advanced configuration options (for developers) ->Toolchain Options ->C Library implementation. Prawdopodobnie nie powinieneś zmieniać tego ustawienia - upewnij się, że budujesz z właściwego źródła repo dla wersji zainstalowanej na routerze.

+0

tak, w końcu działa, dopasowując wersję gcc, wielkie dzięki! Mam inne narzędzia do budowy routera, używając najnowszej wersji gcc i działa poprzez dodanie opcji gcc -Wl, -rpath,/boxer/lib-Wl , - dynamic-linker,/boxer/lib/ld-linux.so.3 i umieścić libc.so etc w kosztownym miejscu jak/boxer/lib/* – coder

Powiązane problemy