☰

Ausführbare Datei ist nach rsync nicht „wirklich da“

tag-icon • tag-icon files rsync executable
Ausführbare Datei ist nach rsync nicht „wirklich da“

Ich gebe den folgenden rsync-Befehl ein (wobei der genaue Pfad und Host verschleiert werden), der zwei Binärdateien kopieren sollte:

rsync -e "ssh -p 443" -a --info=progress2 -z user@remote:/srv/cgi-bin/ .
user@remotes's password: 
  5,970,149 100%    6.78MB/s    0:00:00 (xfr#2, to-chk=0/3)

Soweit ich es beurteilen kann, wurde der Befehl erfolgreich ausgeführt.

root@rapunzel:/s/h/p/cgi-bin # >>> ll
total 5.7M
-rwxrwxr-x 1 marcus marcus 3.9M Sep 10  2014 german-numbers
-rwxrwxr-x 1 marcus marcus 1.9M Sep 10  2014 german-numbers-cgi

Aber wenn ich versuche, eine der Binärdateien auszuführen, erhalte ich den folgenden Fehler

root@rapunzel:/s/h/p/cgi-bin # >>> ./german-numbers
zsh: no such file or directory: ./german-numbers

Es scheint also, dass die Binärdatei nicht „ganz da“ ist, aber andererseits kann ich sie eindeutig öffnen und lesen:

root@rapunzel:/s/h/p/cgi-bin # >>> head -n1 ./german-numbers
ELF04��'4('$444444�=%�=%@%����t��I%������HHHDDP�tdT;%T�T�llQ�td/lib/ld-linux.so.2GNUGNU,B�]2�h$���ɢҒ�S'��� @�P
                                                                                                          ����ݣkĉ����|(�CE���K��8��]���?�������g���FcH▒3
       �_��,�%}�??��>fM7�sn�������F����A{S3a��������,b��)�P▒h�wza�S~�y��*-��y�L
                                                                               �����m���<�lp�6����W$%xZ�G��X{��V���� �!� �!�t����@��ԅ����I��ԅ��� ��Ș
              ��librt.so.1__gmon_start___Jv_RegisterClasseslibutil.so.1libdl.so.2libgmp.so.3__gmpz_tdiv_qr__gmpz_and__gmpz_tdiv_q__gmpz_tdiv_r__gmpz_fdiv_qr__gmpn_gcd_1__gmpz_fdiv_q__gmpz_fdiv_r__gmpz_ior__gmpz_mul_2exp__gmp_set_memory_functions_fini__gmpz_sub__gmpz_xor__gmpz_com__gmpz_gcd__gmpz_fdiv_q_2exp__gmpz_init__gmpz_mul__gmpz_divexact__gmpn_cmp__gmpz_addclock_gettimetimer_deletetimer_settimetimer_createdlopendlerrordlsymlibm.so.6modfldexplibc.so.6_IO_stdin_usedepoll_createfflushstrcpysprintfsetlocalefopenstrncmpftruncatestrrchrregexecpipeftruncate64mmap64siginterruptepoll_waitftellstrncpyforksigprocmaskregfreeunlinkpthread_mutex_lockselectmkdirreallocabortgetpidkillstrdupmkstempstrtodstrtolisattysetmntentmmapctime_rfeoffgetscallocstrlensigemptysetmemset__errno_locationtcsetattrfseekgetpagesizeeventfddup2pause__fxstat64sigaddsetpthread_mutex_unlockstdoutfputcgetrusagefputsregerrormemcpyfclosemprotectmallocraisegetgid__lxstat64nl_langinfohasmntopt__xstat64getenv__ctype_b_locregcompstderrsigdelsetmunmapgetuidgetegid__sysv_signalpthread_mutex_initfwritefreadgettimeofdayiconv_closesigactionepoll_ctlstatfsgeteuidlseek64strchrendmntentutimegetlineiconviconv_opentcgetattrbsearchfcntlgetmntent_rmemmovefopen64access_IO_getcstrcmpstrerror__libc_start_mainvfprintfsysconf__environ__cxa_atexit_edata__bss_start_endGLIBC_2.1GLIBC_2.0GLIBC_2.2GLIBC_2.3GLIBC_2.7GLIBC_2.3.4GLIBC_2.3.2GLIBC_2.1.3

Ich weiß nicht, warum zsh (und nebenbei bemerkt auch bash) diese Datei nicht findet. Hat jemand eine Idee?

Antwort1

Sie versuchen, eine 32-Bit-Programmdatei auf einem 64-Bit-System auszuführen. Dazu müssen Sie die 32-Bit-Bibliotheken installieren, kurz gesagt, Sie müssen Ihr System multilibrär machen.

oder versuchen Sie eine Neukompilierung, indem Sie die Quellen ebenfalls über rsync senden.

Antwort2

Die Ausgabe von file german-numbersund uname -azeigt Details einschließlich der Architektur.

Die Chancen stehen gut, dass Sie kopiert haben

  1. Eine 32bit Datei auf ein 64bit System oder vv
  2. Ein Intel zu ARM oder vv
  3. Ihnen fehlen eine oder mehrere dynamisch verknüpfte Bibliotheken, auf die in der ausführbaren Datei verwiesen wird. Verwenden Sie , ldd german-numbersum die Liste der erforderlichen Bibliotheken anzuzeigen

verwandte Informationen