5

오픈 소스 프로젝트의 바이너리를 컴파일하려고 시도해 사용자가 직접 컴파일하지 않아도됩니다.리눅스에서 모든 x86 머신을위한 일반적인 바이너리 만들기

하나의 32 비트 우분투 컴퓨터 "A"에서 생성 된 일부 이진 파일은보고 된 누락 된 .so 파일에 관한 오류와 함께 32 비트 컴퓨터 "B"에서 작동하지 않습니다.

그러나 컴퓨터 "B"에서 처음부터 컴파일하면 모든 오류가 사라집니다.

대상 컴퓨터에서 코드를 컴파일하면 이러한 오류가 사라지게되는 이유가있을 수 있습니까? 나는 "./configure"와 "make"만 실행했다. "make-install"이 아니기 때문에 .so 파일을 전 세계적으로 사용할 수있게 만들지 않았다.

컴파일러가 시스템 라이브러리에 .so 파일이 없음을 감지 할 수 있으며이 경우 정적 라이브러리를 실행 파일에 연결합니까?

i386 패키지가 모든 x86 시스템에서 실행되도록 Ubuntu에서 패키지를 컴파일하는 방법은 무엇입니까?

답변

6

"이진 호환성"(이 문제에 대한 스택 오버 플로우에는 a tag이 있습니다)라고 생각됩니다. 컴퓨터에서 바이너리를 링크하면 주변 환경이 바이너리에 영향을 미치고 다른 컴퓨터에서 실행 되어도 컴파일 된 환경과 비슷한 환경을 찾습니다.

다른 환경에 대한 허용 오차 이 경우를 바이너리 호환성이라고합니다.

어떻게 작동합니까? 여기

중요한 점은 당신이 다른 시스템에 링커에 같은 옵션을 지정하는 경우에도,이다, 당신은 여전히 ​​다른 바이너리를 얻을 수 있습니다. 예를 들어, 바이너리를 -lfoo이라는 공유 라이브러리에 연결하면 빌드 한 시스템에 가지고있는 foo의 정확한 버전 (예 : libfoo.so.5)이 바이너리에 하드 코드됩니다. 기계 B에서 실행될 때 libfoo.so.4 만 포함될 수 있으며이 파일은 누락 된 파일 libfoo.so.5을 필요로하기 때문에 실행을 거부합니다. 그것이 재 컴파일이 도움이되는 이유이며, 재 컴파일이 도움이되지 않습니다.

우분투 패키지 - 다른 배포판의 패키지는 모두이며 서로 동일한 환경에서 컴파일됩니다. 그것이 그들이 잘 설치하는 이유입니다. 그리고 유통 업체는 각 다음 버전이 이전 버전과 역 호환된다는 것을 감시합니다.

어떻게해야합니까?

다른 배포판과 호환되는 소프트웨어를 만들고 싶다면 생각보다 쉽습니다. 먼저 가장 가까운 배포판에서으로 신청서를 작성하여 에 게시하십시오. 앞에서 언급했듯이 현대 배포판은 일반적으로 하위 호환이 가능하기 때문에 소프트웨어는 문제없이 새로운 배포판에서 실행됩니다.

결과 패키지를보다 철저하게 확인하고 호환성에 대한 자세한 정보를 얻으려면 무료 Linux Application Checker 도구를 사용하십시오. 또한 generic tips for packaging Linux soft에 관심이있을 수 있습니다.

+2

맞아요, 너무 멀리 뒤로 가지 마세요. RHEL 4에서 바이너리를 컴파일하는 것은 현대 배포판에서 잘 작동하지 않을 것입니다. 최소한 libc가 주된 결정 요소이며, 종종 특정 부 버전에 고정되어 있습니다. – Keith

+0

PS. 이것은 또한 일부 상업용 응용 프로그램이 전체 라이브러리 집합과 함께 제공되므로 LD_LIBRARY_PATH를 사용하여 시스템 라이브러리 대신 라이브러리를 사용할 수 있습니다. 또 다른 옵션은 정적 연결입니다. 잘 작동하는 작은 도구의 경우. – Keith

2

Ermine과 같은 프로젝트를 사용하면 공유 라이브러리가 포함 된 동적으로 링크 된 원시 바이너리의 배포판을 만들 수 있습니다.

외부에서는 코드를 정적으로 컴파일 할 수 있습니다. 이렇게하려면 전체 종속성 트리의 소스 코드를 가져 와서 컴파일하고 코드를 빌드 할 때 컴파일 된 바이너리를 참조해야합니다. 정적 바이너리는 다른 공유 라이브러리 (.so 파일)와 비교하여 컴파일 할 수 없습니다. 종속성에 종속성이있는 경우 특히 그렇습니다.

+0

에르 민 (Ermine)이 좋아 보인다. 그러나 그것은 자유롭지 않습니다. 무료 대안을 알고 있습니까? – shivams

3

컴퓨터에서 코드를 컴파일하는 경우이 컴퓨터에서 프로그램을 실행하면 누락 된 libs에 관한 오류가 발생할 가능성이 거의 없습니다. configure를 실행하는 동안 필요한 모든 라이브러리가 감지되고 (이것은 configure, autotools 등의 주된 이유입니다) -lsomelib 및 -I/some/include/patch와 같은 적절한 플래그가 makefile에 작성되고 컴파일러와 링커에 전달됩니다 .

다른 컴퓨터에 실행 파일을 복사하면 컴퓨터에 libs가 잘못된 버전으로 설치되어 있거나 전혀 설치되지 않아 실행되지 않을 수 있습니다.

명시 적으로 지정하지 않는 한 configure 스크립트는 일반적으로 정적 바이너리를 빌드하지 않습니다.

모든 x86 컴퓨터에서 Ubuntu 패키지가 실행되지 않습니다. 그러나 패키지 관리자는 잘못된 라이브러리 나 누락 된 라이브러리가 없는지 확인하기 위해 종속성 확인을 수행하고 그렇지 않은 경우 패키지 설치를 거부합니다. 누락 된 종속성에 상관없이 설치를 강제 실행하면 누락 된 libs와 동일한 문제점에서 다시 실행될 수 있습니다.

패키지가 모든 컴퓨터에서 가능하도록하려면 정적으로 연결하십시오.

특정 배포판 (예 : 우분투)에서 실행하는 것으로 충분하면 직접 패키지를 만들 수 있습니다. 이것은 약간의 노력이 필요합니다.

0

오류가 발생하기 쉬운 접근 방식 (사용자 상호 작용이 필요함) 또는 정적 링크 (GPL에 의해 항상 가능하거나 금지되지는 않음) 대신 라이브러리 경로로 상대 경로를 사용할 수 있습니다 타임스). 링커와 함께 $ORIGIN 플래그를 사용하십시오.

완전한 접근법은 blog (archived version)에 자세히 설명되어 있습니다.

관련 문제