이진 파일 실행 : 파일을 찾을 수 없음


9

비슷한 질문이 있다는 것을 알고 있지만 해결책이나 정확한 사례를 찾지 못했습니다. 바이너리는 GCC 4.7을 사용하여 Arch Linux에서 빌드되었습니다. 패키지는 빌드 시스템에서 제대로 작동합니다. 아래 명령은 다음에서 실행되었습니다.

Linux vbox-ubuntu 3.2.0-29-generic # 46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux

문제의 파일은 여기있습니다 . Linux 64 비트에서 Windows 64 비트 크로스 컴파일러입니다. 압축을 풀면 필요한 모든 것을 포함 ~/하는 단일 ~/mingw64디렉토리 가 제공 됩니다.

내가 ~/mingw64/x86_64-w64-mingw32/bin/as이것을 실행하려고하면 내가 얻는 것입니다.

bash: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: No such file or directory

달리는 file ~/mingw64/x86_64-w64-mingw32/bin/as것은 나에게 준다 :

/home/ruben/mingw64/x86_64-w64-mingw32/bin/as: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x0b8e50955e7919b76967bac042f49c5876804248, not stripped

달리는 ldd ~/mingw64/x86_64-w64-mingw32/bin/as것은 나에게 준다 :

    linux-vdso.so.1 =>  (0x00007fff3e367000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2ceae7e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ceaac1000)
    /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f2ceb0a8000)

나는 진정으로 손실입니다. 도움을 주시면 감사하겠습니다.

편집 : 좀 더 자세한 내용 : 빌드 시스템은 아치 리눅스 (현재 glibc 2.16)입니다. 출력 ls -l은 다음과 같습니다.

-rwxr-xr-x 2 ruben users 1506464 11 aug 23:49 /home/ruben/mingw64/bin/x86_64-w64-mingw32-as

출력 objdump -p은 다음과 같습니다.

Version References:
  required from libz.so.1:
    0x0827e5c0 0x00 05 ZLIB_1.2.0
  required from libc.so.6:
    0x0d696917 0x00 06 GLIBC_2.7
    0x06969194 0x00 04 GLIBC_2.14
    0x0d696913 0x00 03 GLIBC_2.3
    0x09691a75 0x00 02 GLIBC_2.2.5

ldd -vUbuntu 12.04 의 출력 은 다음과 같습니다.

    linux-vdso.so.1 =>  (0x00007fff225ff000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd525c71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5258b4000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd525e9b000)

Version information:
/home/ruben/mingw64/x86_64-w64-mingw32/bin/as:
    libz.so.1 (ZLIB_1.2.0) => /lib/x86_64-linux-gnu/libz.so.1
    libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libz.so.1:
    libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
    libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6:
    ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

테스트 된 다른 OS는 Fedora 17 (glibc 2.15) 및 Ubuntu 12.04 (eglibc 2.15)입니다. zlib 및 glibc 버전 요구 사항이 모두 충족됩니다.


그냥 오타입니까 또는 실제로 '~ / mingw64 / x86_64-w64-mingw32 / as'를 실행하려고합니까? 'bin'폴더가 없습니다.
tripledes

@tripledes 형식으로 수정했습니다.
rubenvb

이상한, 그냥 다운로드 ~, untar 아래에 untar하고 난 exptected 결과를 얻을. ls -l ~ / mingw64 / x86_64-w64-mingw32 / bin / as를 제공 할 수 있습니까?
tripledes

1
libc 버전이 일치하지 않을 수 있습니까? "objdump -p <path / to / as>"를 실행하고 "버전 참조"섹션을 검사하십시오. 상당히 새로운 것으로 간주 될 수있는 GLIBC_2.14에 의존하는 것처럼 보일 수 있습니다. 시스템 버전은 무엇입니까? "readelf -a <path / to / as> | less"및 GLIBC에 대한 grep, 2.14에서 memcpy를 사용하고 있음을 알 수 있습니다. 왜 다른 라이브러리 호출마다 버전이 크게 달라지는 지 모르겠습니다.
svenx

답변:


8

ldd -v as시스템에서 실행 하면 다음을 얻습니다.

./as: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./as)
        linux-vdso.so.1 =>  (0x00007fff89ab1000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1e4c81f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e4c498000)
        /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1e4ca6d000)

따라서이 바이너리가 GLIBC_2.14시스템에서 누락 된 기호를 찾는 것처럼 보입니다 . Svenx가 지적했듯이 memcpy@@GLIBC_2.14기호를 검색하는 것처럼 보입니다 . memcpy새 버전이 제공된 이유 에 대한 자세한 내용 은이 버그 보고서에 설명 되어 있습니다.

glibc대상 시스템에 새 버전을 설치하면 문제가 해결됩니다. 이전 버전의에서도 여전히 작동하도록 바이너리를 재 구축하려는 경우 여기에glibc 나열된 것과 같은 트릭을 시도 할 수 있습니다 . memcpy필요한 심볼 의 특정 버전을 제공하는 심을 사용할 수도 있지만 약간 해키됩니다.


업데이트를 읽은 후 : 그렇습니다. 문제가 아닙니다. 그러나 나는 그것을 발견했다고 생각합니다 : 바이너리가 /lib/ld-linux-x86-64.so.2Ubuntu 12.04 시스템에는없는 인터프리터를 요청하고 있습니다 :

$ readelf -a ./as | grep interpreter
      [Requesting program interpreter: /lib/ld-linux-x86-64.so.2]

반면 ldd에 그것을 찾기 위해 알고 /lib64대신에, 나는 커널이 바이너리를 실행하려고 할 때 알고하지 않고 파일의 요청 인터프리터를 찾을 수 없습니다 가정합니다. 인터프리터를 통해 수동으로 실행할 수 있습니다.

$ pwd
/home/jim/mingw64/x86_64-w64-mingw32/bin
$ ./as --version
-bash: ./as: No such file or directory
$ /lib64/ld-linux-x86-64.so.2 ./as --version
GNU assembler (rubenvb-4.7.1-1-release) 2.23.51.20120808
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.

이것이 올바르게 작동하는지 100 % 확신하지 못합니다. 시스템 gcc에서이 방법으로 실행 하면 세그먼트 오류가 발생합니다. 그러나 그것은 적어도 다른 문제입니다.


1
이 경우라면 좋을 것입니다. :(
rubenvb

내 답변을 업데이트했습니다.
Jim Paris

와우 이런 종류의 짜증. 나는이 문제를 해결하고 아치를 계속 유지하는 적절한 방법을 생각할 수 없다. 훌륭한 아이디어가 있습니까?
rubenvb

1
실제로는 아닙니다. 더 - 아치은 바보되는 파일 시스템 계층 구조 표준이 명확 라이브러리에 있어야 있다고 /lib64하여, AMD64에서, 분명히 아치 수동으로 GCC 소스가이를 변경하는 패치 보장 에서 다른 모든 리눅스 배포판과 호환성이. 기괴한 추론에 대해서는 이 버그 보고서 의 의견을 참조하십시오 . 나에게 이것은 아치 리눅스에서 멀리 떨어져 있다는 분명한 경고 신호일 것이다.
Jim Paris

1
즉, patchelf를 사용하여 인터프리터 위치를 변경할 수 있습니다 . 이 문제를 겪고있는 다른 사람에 대해서는 이 게시물 을 참조하십시오 patchelf.
Jim Paris

0

문제는 64 비트 시스템에서 32 비트 바이너리를 실행할 때 "찾을 수 없음"메시지 의 변형입니다 . 동적 로더가없는 실행 파일이 있습니다.

귀하의 경우 동적 로더 /lib/ld-linux-x86-64.so.2가 존재하지만 다른 위치에 /lib64/ld-linux-x86-64.so.2있습니다. 프로그램을 작동시키는 가장 간단한 방법은 심볼릭 링크를 만드는 것입니다.

ln -s ../lib64/ld-linux-x86-64.so.2 /lib/

글쎄, 이것은 재배포를위한 패키지이기 때문에 그러한 심볼릭 링크는 실제로 내 통제가 아닙니다. 나는 리눅스 바이너리가 더 이식성이 있다고 생각했다.
rubenvb
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.