태그 보관물: installation

installation

소스에서 컴파일하는 법 배우기 (Unix / Linux / OSX에서) 종종 있습니다.

가능한 경우 패키지 (MacPorts / apt-get)에서 소프트웨어를 설치하는 동안 소스에서 패키지를 컴파일해야하는 경우가 종종 있습니다. ./configure && make && sudo make install일반적으로 충분하지만 때로는 작동하지 않으며 때로는 작동하지 않는 경우가 종종 있습니다. 이것은 거의 항상 어떤 방식으로 다른 라이브러리 종속성과 관련이 있습니다.

다음을 배우고 싶습니다.

  • 어떤 인수를 전달해야하는지 어떻게 알 수 ./configure있습니까?
  • OS X / Linux에서 공유 라이브러리가 작동하는 방식-파일 시스템에서 ./configure && make상주하는 위치, 찾는 방법, 링크시 실제로 발생하는 상황
  • 공유 라이브러리와 정적으로 링크 된 라이브러리의 실제 차이점은 무엇입니까? 왜 정적으로 모든 것을 정적으로 링크 할 수 없습니까 (요즘 RAM과 디스크 공간이 저렴합니다) 따라서 이상한 라이브러리 버전 충돌을 피할 수 있습니까?
  • 어떤 라이브러리와 어떤 버전을 설치했는지 어떻게 알 수 있습니까?
  • 일반 시스템을 중단하지 않고 여러 버전의 라이브러리를 설치하려면 어떻게해야합니까?
  • 내가하면 하고 그렇지 않으면 패키지를 사용하여 관리되는 시스템에 소스 재료를 설치, 그렇게하는 가장 깨끗한 방법은 무엇입니까?
  • 소스에서 무언가를 어렴풋이 컴파일한다고 가정하면 어떻게 다른 사람들이 같은 농구대를 뛰어 넘을 필요가 없도록 패키지로 만들 수 있습니까? 특히 OS X에서 …
  • 이 기능을 익히려면 마스터해야하는 명령 줄 도구는 무엇입니까? otool, pkg-config 등과 같은 것들

나는 여기에 꽤 많은 시간과 노력을 투자 할 의향이 있습니다. 위의 질문에 직접 대답하고 싶지는 않습니다. 지식 나는 실제로 무슨 일이 일어나고 있는지 이해해야하므로 스스로 문제를 찾아야합니다.



답변

모든 것에 직접 대답 해 드려 죄송하지만 유용한 자습서, FAQ 등을 모릅니다. 기본적으로 다음은 데스크톱 앱 (배포에 도움이 됨), 좌절 및 인터넷 검색의 8 년입니다.

1. ./configure에 전달할 인수를 어떻게 알 수 있습니까?

실제로 연습하십시오. Autotools는 일관성이 있기 때문에 충분히 쉽습니다. 그러나 cmake 또는 사용자 정의 빌드 스크립트를 사용하여 많은 것들이 있습니다. 일반적으로 구성하기 위해 아무것도 전달하지 않아도됩니다. 시스템이 foo-tool을 빌드 할 수 있는지 여부를 알아 내야합니다.

구성 및 GNU 도구는 모두 /, / usr 및 / usr / local에서 종속성을 찾습니다. MacPorts 또는 Fink에서 종속성을 설치 한 경우 문제가 발생하는 다른 위치를 설치하는 경우 GNU 도구가 이러한 종속성을 찾을 수 있도록 셸 환경을 구성하거나 수정하려면 플래그를 전달해야합니다.

2. OS X / Linux에서 공유 라이브러리가 작동하는 방식-파일 시스템에 상주하는 위치, ./configure && 검색 방법, 링크시 실제로 발생하는 상황

Linux에서는 동적 링커가 찾을 수있는 경로에 설치해야합니다. 이는 LD_LIBRARY_PATH환경 변수와 /etc/ld.conf의 내용으로 정의됩니다 . Mac에서는 Xcode 프로젝트가 아닌 한 대부분의 오픈 소스 소프트웨어와 거의 동일합니다. DYLD_LIBRARY_PATH대신 env 변수가 있습니다.

링커가 라이브러리를 검색하는 기본 경로가 있습니다. / lib : / usr / lib : / usr / local / lib입니다.

CPATH 변수 또는 CFLAGS 또는 다른 많은 환경 변수를 사용하여이를 보완 할 수 있습니다 (실제로는 복잡함). CFLAGS는 다음과 같이 제안합니다.

CFLAGS = “$ CFLAGS -L / new / path”내보내기

-L 매개 변수는 링크 경로에 추가합니다.

현대는 pkg-config 도구를 사용합니다. 최신 설치 항목은 라이브러리와 라이브러리의 위치 및 링크 방법을 설명하는 .pc 파일도 설치합니다. 이것은 인생을 더 쉽게 만들 수 있습니다. 그러나 OS X 10.5와 함께 제공되지 않으므로 설치해야합니다. 또한 많은 기본 뎁은 그것을 지원하지 않습니다.

연결 동작은 “런타임에이 함수를 해결”하는 것입니다. 실제로 큰 문자열 테이블입니다.

3. 공유 라이브러리와 정적으로 링크 된 라이브러리의 실제 차이점은 무엇입니까? 왜 정적으로 모든 것을 정적으로 링크 할 수 없습니까 (요즘 RAM과 디스크 공간이 저렴합니다) 따라서 이상한 라이브러리 버전 충돌을 피할 수 있습니까?

정적 라이브러리 파일에 링크하면 코드가 응용 프로그램의 일부가됩니다. 해당 라이브러리에 거대한 .c 파일이 하나 있고 응용 프로그램으로 컴파일 한 것처럼 보입니다.

동적 라이브러리는 동일한 코드를 갖지만 앱이 실행될 때 런타임에 코드가 앱에로드됩니다 (간단한 설명).

정적으로 모든 것에 링크 할 수 있지만, 거의 모든 빌드 시스템이이를 쉽게 만들지 않습니다. 빌드 시스템 파일을 수동으로 편집해야합니다 (예 : Makefile.am 또는 CMakeLists.txt). 그러나 다른 버전의 라이브러리가 필요한 것을 정기적으로 설치하고 병렬로 설치하는 것이 어려운 경우에는 학습 할 가치가 있습니다.

트릭은 링크 라인을 -lfoo에서 -l / path / to / static / foo.a로 변경하는 것입니다.

찾아서 바꿀 수 있습니다. 그런 다음 도구가 ldd foo 또는 otool -L foo를 사용하여 .so 또는 dylib에 연결되어 있지 않은지 확인하십시오.

또 다른 문제는 모든 라이브러리가 정적 라이브러리로 컴파일되는 것은 아닙니다. 많은 사람들이 그렇습니다. 그러나 MacPorts 또는 Debian은 제공하지 않기로 결정했을 수 있습니다.

4. 설치 한 라이브러리와 버전을 어떻게 알 수 있습니까?

해당 라이브러리에 대한 pkg-config 파일이 있으면 쉽습니다.

pkg-config –list-all

그렇지 않으면 종종 쉽게 할 수 없습니다. dylib는 라이브러리 버전과 동일한 soname (예 : foo.0.1.dylib, soname은 0.1)을 가질 수 있습니다. 그러나 이것은 필요하지 않습니다. soname은 이진 계산 기능이므로 라이브러리의 함수 형식을 변경하면 soname의 주요 부분을 충돌시켜야합니다. 예를 들어 얻을 수 있습니다. 2.0 라이브러리의 버전 14.0.5 soname 이것은 일반적이지 않지만.

나는 이런 종류의 일에 좌절하고 Mac에서 이것을위한 솔루션을 개발했으며 다음에 그것에 대해 이야기하고 있습니다.

5. 일반 시스템을 손상시키지 않고 여러 버전의 라이브러리를 어떻게 설치할 수 있습니까?

이것에 대한 나의 해결책은 여기에 있습니다 : http://github.com/mxcl/homebrew/

소스에서 설치하는 것을 좋아하고 일부 패키지 관리를 통해 쉽게 만들 수있는 도구를 원했습니다. 예를 들어 Homebrew를 사용하여 빌드합니다. 소스에서 나왔지만 특별한 접두사로 설치하십시오.

/usr/local/Cellar/wget/1.1.4

그런 다음 homebrew 도구를 사용하여 모든 것을 / usr / local에 심볼릭 링크하므로 / usr / local / bin / wget 및 /usr/local/lib/libwget.dylib가 있습니다.

나중에 다른 버전의 wget이 필요한 경우 병렬로 설치하고 / usr / local 트리에 연결된 버전을 변경할 수 있습니다.

6. 다른 방법으로 패키지를 사용하여 관리되는 시스템에 소스의 자료를 설치하는 경우 가장 깨끗한 방법은 무엇입니까?

나는 Homebrew 방법이 가장 깨끗하다고 ​​생각하므로 사용하거나 이에 상응하는 방법을 사용하십시오. / usr / local / pkgs / name / version에 설치하고 나머지를 symlink 또는 하드 링크로 설치하십시오.

/ usr / local을 사용하십시오. 존재하는 모든 빌드 도구는 종속성과 헤더를 검색합니다. 당신의 인생은 훨씬 쉬워 질 입니다.

7. 소스에서 무언가를 어렴풋하게 컴파일한다고 가정하면, 다른 사람들이 같은 농구대를 뛰어 넘을 필요가 없도록 어떻게 패키지를 만들 수 있습니까? 특히 OS X에서 …

종속성이 없으면 빌드 디렉토리를 압축 해제하여 “make install”을 수행 할 수있는 다른 사람에게 제공 할 수 있습니다. 그러나 동일한 버전의 OS X에 대해서만 안정적으로이 작업을 수행 할 수 있습니다. Linux에서는 아마도 동일한 커널 버전 및 libc 부 버전의 유사한 Linux (예 : Ubuntu)에서 작동 할 수 있습니다.

바이너리를 유닉스에 배포하기가 쉽지 않은 이유는 바이너리 호환성 때문입니다. GNU 사람들과 다른 사람들은 이진 인터페이스를 자주 바꿉니다.

기본적으로 바이너리를 배포하지 않습니다. 상황은 아마도 매우 이상한 방식으로 깨질 것입니다.

Mac에서 가장 좋은 방법은 macports 패키지를 만드는 것입니다. 누구나 macports를 사용합니다. Linux에는 너무 많은 빌드 시스템과 조합이 있으므로 이상한 구성으로 x 도구를 작성하는 방법에 대한 블로그 항목을 작성하는 것보다 더 나은 조언은 없다고 생각합니다.

macports 또는 homebrew에 대한 패키지 설명을 작성하면 누구나 해당 패키지를 설치할 수 있으며 종속성 문제도 해결합니다. 그러나 이것은 쉬운 일이 아니며, 메인 macports 트리에 macports 레시피를 포함시키는 것도 쉽지 않습니다. 또한 macports는 이국적인 설치 유형을 지원하지 않으며 모든 패키지에 대해 하나의 선택을 제공합니다.

Homebrew의 미래 목표 중 하나는 웹 사이트의 링크를 클릭 할 수있게하는 것입니다 (예 : homebrew : // blah 및 Ruby 스크립트를 다운로드하고 해당 패키지의 dep를 설치 한 다음 앱을 빌드합니다). 아직 완료하지는 않았지만 선택한 디자인을 고려하면 너무 까다 롭지 않습니다.

8.이 기능을 익히기 위해 마스터해야하는 명령 줄 도구는 무엇입니까? otool, pkg-config 등과 같은 것들

otool은 나중에 만 유용합니다. 빌드 된 바이너리 링크가 무엇인지 알려줍니다. 빌드해야하는 도구의 종속성을 파악할 때는 쓸모가 없습니다. pkg-config의 경우 종속성을 사용하기 전에 이미 설치 했으므로 마찬가지입니다.

내 툴체인은 README 및 INSTALL 파일을 읽고 configure –help를 수행합니다. 빌드 출력을보고 정상인지 확인하십시오. 빌드 오류를 구문 분석하십시오. 아마도 나중에 serverfault에 문의하십시오 🙂


답변

이 거대한 주제를 그렇게 (Linux 및 마하-O OS X에서의 ELF) 리눅스의 공유 라이브러리를 시작할 수있다, 울리히 Drepper가 좋은가 DSO를 작성 소개 리눅스 사용할 수에 공유 라이브러리의 일부 역사를 다루고 있습니다 (동적 공유 객체) 중요한 이유를 포함하여 여기에

Ulrich는 또한 정적 링크가 유해한 것으로 간주되는 이유를 설명 합니다. 여기서 핵심 업데이트 중 하나는 보안 업데이트입니다. 정적으로 광범위하게 링크 된 공통 라이브러리 (예 : zlib)의 버퍼 오버 플로우는 분배에 큰 오버 헤드를 유발할 수 있습니다. 이는 zlib 1.1.3에서 발생했습니다 ( Red Hat 권고 )

꼬마 요정

링커 ld.so 매뉴얼 페이지

man ld.so

런타임 동적 링크와 관련된 기본 경로 및 파일을 설명합니다. 최신 Linux 시스템에서는 /etc/ld.so.conf를 통해 추가 된 추가 경로가 일반적으로 /etc/ld.so.conf에 포함되어 있습니다.

ld.so 구성을 통해 동적으로 사용 가능한 항목을 보려면 다음을 실행하십시오.

ldconfig -v -N -X

DSO 하우투를 읽으면 OS X의 Mach-O에 이러한 원칙이 어떻게 적용되는지 이해하기 위해 좋은 기본 지식 수준을 제공해야합니다.

마 하오

OS X에서 이진 형식은 Mach-O입니다. 링커에 대한 로컬 시스템 설명서는

man dyld

마하 형식의 문서는 애플에서 사용할 수 있습니다

유닉스 빌드 툴

일반적인 configure, make, make install과정은 일반적으로 가지고 GNU의 autotools를에 의해 제공되는 온라인 책 구성의 역사의 일부가 / 분할과 GNU 툴체인을 구축 다룹니다. Autoconf 는 테스트를 사용하여 대상 빌드 시스템에서 기능 가용성을 결정하고 M4 매크로 언어 를 사용하여이를 구현합니다 . Automake 는 기본적으로 Makefile의 템플릿 방법으로, 일반적으로 Makefile.am이라고하는 템플릿으로 autoconf (configure 스크립트)의 출력이 Makefile로 변환됩니다.

GNU의 헬로 프로그램은 GNU 툴체인을 이해하기위한 좋은 본보기 역할을 – 그리고 매뉴얼 autotools를 문서가 포함되어 있습니다.


답변

사이먼! 나는 당신이 어떻게 느끼는지 알고있다; 나는 리눅스를 배우는이 부분에도 어려움을 겪었다. 내 자신의 경험을 바탕으로, 나는 당신이 다루는 몇 가지 항목 (주로 나 자신을위한 참고 자료!)에 대한 자습서를 썼습니다 : http://easyaspy.blogspot.com/2008/12/buildinginstalling-application-from.html . 간단한 Python 응용 프로그램을 빌드 / 설치하는 방법에 대한 내 의견에 감사드립니다. 🙂

이것이 도움이되기를 바랍니다! 그리고 행복한 컴파일.

팀 존스


Ubuntu Linux에서 소스에서 애플리케이션 빌드 / 설치

우분투 리포지토리는 훌륭한 응용 프로그램으로 가득 차 있지만 리포지토리에 없거나 (데비안 패키지가없는) “필수 도구”를 만나야합니다. 리포지토리보다 최신 버전입니다. 너 뭐하니? 음, 소스에서 애플리케이션을 빌드해야합니다! 걱정하지 마십시오. 소리처럼 복잡하지는 않습니다. 랭크 아마추어가 된 경험을 바탕으로 한 몇 가지 팁이 있습니다! (이 예제에서 Ubuntu를 사용하는 동안 일반적인 개념은 Fedora와 같은 대부분의 Unix / Linux 배포판 및 Windows의 Cygwin 플랫폼에도 적용 할 수 있어야합니다.)

소스에서 대부분의 응용 프로그램을 빌드 (컴파일)하는 기본 프로세스는 configure-> compile-> install 순서를 따릅니다. 이러한 작업을 수행하는 일반적인 Unix / Linux 명령은 config-> make-> make install입니다. 경우에 따라 모든 명령을 단일 명령으로 결합 할 수 있음을 보여주는 웹 페이지를 찾을 수도 있습니다.

$ config && make && make install

물론이 명령은 이러한 단계 중 아무 문제가 없다고 가정합니다. 여기가 재미가 온다!

시작하기

이전에 시스템의 소스에서 응용 프로그램을 컴파일하지 않은 경우 gcc컴파일러 스위트 와 같은 일반적인 개발 도구 , 일부 공통 헤더 파일 (이미 작성된 코드로 생각 하십시오)을 사용하여 응용 프로그램을 설정해야합니다 설치중인 프로그램에서 사용하는 다른 사람 및 make 도구) 다행히 우분투에는 build-essential이것을 설치할 메타 패키지 가 있습니다. 설치하려면 (또는 이미 가지고 있는지 확인하십시오!) 터미널에서 다음 명령을 실행하십시오.

$ sudo apt-get install build-essential

기본 설정이 완료되었으므로 응용 프로그램 소스 파일을 다운로드하여 “홈”디렉토리와 같은 읽기 / 쓰기 권한이있는 디렉토리에 저장하십시오. 일반적으로 파일 확장자는 .tar.gz또는 로 아카이브 파일에 있습니다 .tar.bz2. 는 .tar단순히 상대 디렉토리 구조를 보존 파일의 그룹 인 “테이프 아카이브”의 것을 의미한다. .gz널리 사용되는 Unix / Linux 압축 형식 인 gzip (GNU zip) 의 약자입니다. 마찬가지로 .bz2bzip2 의 약어로 gzip보다 더 높은 압축 (작은 압축 파일 크기)을 제공하는 새로운 압축 형식입니다.

소스 파일을 다운로드 한 후 터미널 창 (Ubuntu 메뉴의 시스템 터미널)을 열고 파일을 저장 한 디렉토리로 변경하십시오. ( ~/download이 예제에서 사용하겠습니다 . 여기에서 ‘~’는 “home”디렉토리의 바로 가기입니다.) tar 명령을 사용하여 다운로드 한 아카이브 파일에서 파일을 추출하십시오.

파일이 gzip 아카이브 인 경우 (예 :로 끝남 .tar.gz) 다음 명령을 사용하십시오.

            $ tar -zxvf filename.tar.gz

파일이 bzip2 아카이브 인 경우 (예 :로 끝남 .tar.bz2) 다음 명령을 사용하십시오.

            $ tar -jxvf filename.tar.gz

팁 : 아카이브를 추출하기 위해 모든 명령 행 스위치를 기억하지 않으려면 dtrx (내가 좋아하는 것!) 또는 deco (더 인기있는) 유틸리티 중 하나 (또는 ​​둘 다)를 사용하는 것이 좋습니다. 이 유틸리티 중 하나를 사용하면 유틸리티 이름 (dtrx 또는 deco)과 파일 이름 만 입력하면 나머지는 모두 수행됩니다. 이 두 가지 모두 실행 가능한 대부분의 아카이브 형식을 처리하는 방법을 “알고”큰 오류 처리 기능을 가지고 있습니다.

소스에서 빌드 할 때 발생할 수있는 두 가지 일반적인 유형의 오류가 있습니다.

  1. 구성 스크립트 (일반적으로 config 또는 configure)를 실행하여 설정과 관련된 make 파일을 만들 때 구성 오류가 발생합니다.
  2. make 파일이 생성 된 후 make 명령을 실행할 때 컴파일러 오류가 발생하고 컴파일러가 필요한 일부 코드를 찾을 수 없습니다.

이들 각각을 살펴보고이를 해결하는 방법에 대해 논의 할 것입니다.

구성 및 구성 오류

소스 코드 아카이브 파일을 추출한 후 터미널에서 추출 된 파일이 포함 된 디렉토리로 변경해야합니다. 일반적으로이 디렉토리 이름은 파일 이름과 동일 .tar.gz하거나 .tar.bz2확장자가 없습니다 . 그러나 때때로 디렉토리 이름은 버전 정보가없는 응용 프로그램의 이름 일뿐입니다.

소스 디렉토리에서 README파일 및 / 또는 INSTALL파일 (또는 유사한 이름을 가진 것)을 찾으십시오 . 이러한 파일에는 일반적으로 종속성에 대한 정보를 포함하여 응용 프로그램을 빌드 / 컴파일하고 설치하는 방법에 대한 유용한 정보가 포함되어 있습니다. “종속성”은 성공적으로 컴파일하는 데 필요한 다른 구성 요소 나 라이브러리의 이름입니다.

당신이 읽은 후 README및 / 또는 INSTALL파일을 (그리고, 희망 응용 프로그램에 대한 모든 관련 온라인 문서 보았다), 파일 이름 (파일에 설정된 “X”권한이) 실행 파일을 찾아 configconfigure. 때때로 파일의 확장자는 .sh(예 🙂 일 수 config.sh있습니다. 일반적으로 컴파일을위한 “정상적인”환경이 있는지 확인하기 위해 다른 유틸리티를 실행하는 쉘 스크립트입니다. 즉, 필요한 모든 것이 설치되어 있는지 확인합니다.

팁 : 이것이 구성 파일 대신 Python 기반 응용 프로그램 인 경우이라는 파일을 찾아야합니다 setup.py. 파이썬 응용 프로그램은 일반적으로 설치가 매우 간단합니다. 이 응용 프로그램을 루트로 설치하려면 (예 : Ubuntu에서 다음 명령 앞에 sudo를 입력)이 명령을 실행하십시오.

    $ python setup.py install

그게 당신이해야 할 모든 것입니다. 이 자습서의 나머지 부분을 건너 뛰고 응용 프로그램 사용 및 즐기기로 직접 진행할 수 있습니다.

터미널에서 구성 스크립트를 실행하십시오. 일반적으로 일반 사용자 계정으로 구성 스크립트를 실행할 수 있습니다.

$ ./config

스크립트는 일부 메시지를 표시하여 스크립트가 수행중인 작업에 대한 아이디어를 제공합니다. 스크립트는 성공 여부를 표시하고 실패한 경우 실패 원인에 대한 정보를 제공합니다. 오류 메시지가 표시되지 않으면 일반적으로 모든 것이 제대로되었다고 가정 할 수 있습니다.

구성 스크립트처럼 보이는 스크립트를 찾지 못하면 일반적으로 응용 프로그램이 매우 단순하고 플랫폼에 독립적이라는 것을 의미합니다. 제공된 Makefile시스템은 모든 시스템에서 작동 하므로 아래의 빌드 / 컴파일 단계로 건너 뛸 수 있습니다 .

이 학습서에서는 애플리케이션 빌드시 발생할 수있는 오류 유형의 예로 Newsbeuter라는 텍스트 기반 RSS 리더를 사용합니다. Newsbeuter의 경우 구성 스크립트 이름은입니다 config.sh. 내 시스템에서을 실행할 때 config.sh다음 오류가 발생합니다.

tester@sitlabcpu22:~/download/newsbeuter-1.3$ ./config.sh
Checking for package sqlite3... not found

You need package sqlite3 in order to compile this program.
Please make sure it is installed.

약간의 연구를 한 결과, 실제로 sqlite3응용 프로그램이 설치되어 있음을 알았습니다 . 그러나 소스에서 빌드하려고하므로 config.sh실제로 찾고있는 것은에 대한 개발 라이브러리 (헤더)입니다 sqlite3. 우분투에서 대부분의 패키지에는로 끝나는 관련 개발 대응 패키지가 -dev있습니다. Fedora와 같은 다른 플랫폼은 종종 -devel개발 패키지 의 패키지 접미사를 사용 합니다.

sqlite3개발 패키지에 적합한 패키지를 찾으려면 apt-cacheUbuntu 의 유틸리티 (및 마찬가지로 yumFedora 의 유틸리티)를 사용할 수 있습니다.

tester@sitlabcpu22:~/download/newsbeuter-1.3$ sudo apt-cache search sqlite

이 명령은 상당히 큰 결과 목록을 반환하므로 적절한 패키지를 결정하기 위해 약간의 탐정 작업을 수행해야합니다. 이 경우 적절한 패키지는 libsqlite3-dev입니다. 때로는 우리가 찾고있는 패키지 lib에 동일한 패키지 이름 plus 대신 접두사가 붙습니다 -dev. 때로는 여러 응용 프로그램에서 사용할 수있는 공유 라이브러리를 찾고 있기 때문입니다. 설치하려면 libsqlite3-dev터미널에서 일반적인 apt-get install 명령을 실행하십시오.

tester@sitlabcpu22:~/download/newsbeuter-1.3$ sudo apt-get install libsqlite3-dev

이제이 config.sh종속성 문제를 해결하고 더 이상 종속성 문제가 없는지 확인하기 위해 다시 실행 해야합니다. (여기에 표시하지 않지만 Newsbeuter의 경우 libcurl4-openssl-dev패키지 도 설치해야했습니다 .) 또한 개발 패키지 (예 :)를 설치 libsqlite3-dev하고 관련 응용 프로그램 패키지 (예 :)는 설치 sqlite3하지 않은 경우 이미 설치되어 있으면 대부분의 시스템은 관련 응용 프로그램 패키지를 자동으로 동시에 설치합니다.

구성이 성공적으로 실행되면 하나 이상의 make 파일이 작성됩니다. 이러한 파일은 일반적으로 이름이 지정됩니다 Makefile(파일 이름 대소 문자는 Unix / Linux에서 중요합니다!). 빌드 패키지 src에 등의 하위 디렉토리가 포함 된 Makefile경우 각 하위 디렉토리 에도.

빌드 및 컴파일 오류

이제 애플리케이션을 실제로 컴파일 할 준비가되었습니다. 이것을 종종 건물이라고하며 이름은 실제 구성 과정에서 차용됩니다. 일반적으로 여러 소스 코드 파일 인 응용 프로그램의 다양한 “피스”가 결합되어 전체 응용 프로그램을 구성합니다. make 유틸리티는 빌드 프로세스를 관리하고 실제로 작업을 수행하기 위해 컴파일러 및 링커와 같은 다른 응용 프로그램을 호출합니다. 대부분의 경우 구성을 실행 한 디렉토리에서 make (일반 사용자 계정으로)를 실행하기 만하면됩니다. (Qt 라이브러리로 작성된 응용 프로그램 컴파일과 같은 일부 경우에는 qmake와 같은 다른 “래퍼”응용 프로그램을 대신 실행해야합니다. 자세한 내용 은 항상 README및 / 또는 INSTALL문서를 확인하십시오.)

위의 구성 스크립트와 마찬가지로 터미널에서 make (또는 유사한 유틸리티)를 실행하면 실행중인 내용과 경고 및 오류에 대한 일부 메시지가 표시됩니다. 일반적으로 경고는 주로 응용 프로그램 개발자를위한 것이며 위반되는 표준 사례가 있다는 경고를 무시할 수 있습니다. 일반적으로 이러한 경고는 응용 프로그램 기능에 영향을 미치지 않습니다. 반면에 컴파일러 오류를 처리해야합니다. Newsbeuter를 사용하여 make를 실행했을 때 한동안 문제가 없었지만 오류가 발생했습니다.

tester@sitlabcpu22:~/download/newsbeuter-1.3$ make
...
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/configparser.o -c src/configparser.cpp
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/colormanager.o -c src/colormanager.cpp
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:5:18: error: stfl.h: No such file or directory
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:33: error: ISO C++ forbids declaration of \u2018stfl_form\u2019 with no type
./include/stflpp.h:33: error: expected \u2018;\u2019 before \u2018*\u2019 token
./include/stflpp.h:34: error: ISO C++ forbids declaration of \u2018stfl_ipool\u2019 with no type
./include/stflpp.h:34: error: expected \u2018;\u2019 before \u2018*\u2019 token
make: *** [src/colormanager.o] Error 1

첫 번째 오류가 발생하자마자 make 프로세스가 중지됩니다. 컴파일러 오류 처리는 때로는 까다로울 수 있습니다. 문제에 대한 단서의 오류를 살펴 봐야합니다. 일반적으로 문제는 확장명이 보통 .h또는 .hpp인 일부 헤더 파일 이 누락 된 것입니다. 위의 오류가 발생하면 stfl.h헤더 파일을 찾을 수 없다는 문제가 분명합니다 . 이 예에서 볼 수 있듯이 오류 메시지의 첫 번째 줄을보고 문제의 근본 원인을 찾기 위해 노력하고 싶습니다.

Newsbeuter 문서를 살펴본 후 (시작하기 전에 수행해야했지만 튜토리얼 의이 부분은별로 의미가 없습니다!) STFL이라는 타사 라이브러리가 필요하다는 것을 알았습니다. 이 경우 어떻게해야합니까? 글쎄, 우리는 본질적으로 필요한 라이브러리에 대해 정확히 동일한 프로세스를 반복합니다. 라이브러리를 얻고 라이브러리에 대해 configure-build-install 프로세스를 실행 한 다음 원하는 응용 프로그램 빌드를 다시 시작하십시오. 예를 들어 STFL의 경우 libncursesw5-dev제대로 빌드하려면 패키지 를 설치해야했습니다 . (보통, 다른 필수 응용 프로그램을 설치 한 후 원래 응용 프로그램에서 구성 단계를 다시 실행할 필요는 없지만 결코 아프지 않습니다.)

STFL 툴킷을 성공적으로 설치 한 후 Newsbeuter의 작성 프로세스가 성공적으로 실행되었습니다. make 프로세스는 일반적으로 오류가 발생한 지점에서 벗어납니다. 따라서 이미 성공적으로 컴파일 된 파일은 다시 컴파일되지 않습니다. 모든 것을 다시 컴파일하려면 make clean all을 실행하여 컴파일 된 객체를 제거한 다음 make를 다시 실행할 수 있습니다.

설치

빌드 프로세스가 완료되면 응용 프로그램을 설치할 수 있습니다. 대부분의 경우 파일 시스템의 공통 영역 (예 : /usr/bin또는 /usr/share/bin등)에 응용 프로그램을 설치하려면 루트로 설치를 실행해야합니다. 설치는 전체 프로세스에서 가장 간단한 단계입니다. 설치하려면 터미널에서 다음을 실행하십시오.

$ make install

이 프로세스의 출력에서 ​​오류가 있는지 확인하십시오. 모든 것이 성공하면 터미널에서 명령 이름을 실행할 수 있어야합니다. (GUI 응용 프로그램이거나 응용 프로그램 실행이 끝날 때까지 터미널 세션을 사용할 수없는 경우 명령 줄의 끝에 & 끝에 추가하십시오.)

소스에서 응용 프로그램을 빌드 할 때 일반적으로 Ubuntu의 GUI 메뉴에 아이콘이나 바로 가기를 추가하지 않습니다. 이것을 수동으로 추가해야합니다.

그리고 그것은 기본적으로 우분투의 소스에서 응용 프로그램을 빌드하고 설치하는 잠재적 인 반복적이지만 프로세스입니다. 이 작업을 몇 번만 수행하면 두 번째 자연이됩니다!


답변

./configure –help는 GNU autotools가 생성 한 구성 파일에 대해 많은 정보를 제공합니다. 대부분의 경우 기능을 활성화하지 않고 –with /-로 제공됩니다 (라이브러리를 찾을 위치를 말하기 위해 “공유”와 같은 추가 매개 변수를 사용할 수 있음).

다른 중요한 것들은 –prefix (기본적으로 / usr / local / 대부분의 경우) 설치 위치를 말해줍니다 (패키지를 빌드하는 경우 일반적으로 –prefix = / usr 또는 –prefix = / opt / YourPackage).

Linux에서 / lib, / usr / lib 및 / usr / local / lib는 일반적으로 내 gcc에서 검색되며 ldconfig의 기본 구성에 포함됩니다. 정당한 이유가없는 한, 여기가 도서관을 원하는 곳입니다. 그러나 /etc/ld.so.conf는 추가 항목을 나열 할 수 있습니다.

“gcc -l”을 실행하고 오류가 있는지 확인하여 구성하고 찾을 수 있습니다. CFLAGS 매개 변수에 “-L”을 추가하여 검색 할 경로를 추가 할 수 있습니다.

여러 버전을 설치할 수 있으며, 이전 버전과 연결된 소프트웨어는 링크 된 상태로 유지되지만 (ldd를 실행하여 Linux에서 바인딩을 찾음) 새 컴파일은 일반적으로 시스템에서 최신 버전의 동적 라이브러리를 대상으로합니다.

대부분의 소프트웨어는 특히 libtool을 사용하는 경우 동적 라이브러리를 가정하므로 사소하지 않은 앱은 정적으로 올바르게 빌드되지 않을 수 있습니다.

ls -l은 설치된 라이브러리를 찾는 가장 좋은 방법입니다.

그리고 그것이 내가 정보에서 벗어난 곳입니다. 패키지를 잘 사용하는 방법 : 모름 가능한 경우 문제를 피하기 위해 물건을 포장으로 포장하려고합니다.


답변

“./configure에 전달할 인수를 어떻게 알 수 있습니까?”

일반적으로 ./configure –help는 원하는 것을 알려줍니다.

“설치 한 라이브러리와 버전을 어떻게 알 수 있습니까?”

시스템에 따라 다릅니다. 한 가지 방법은 find /|grep libname|less일반적으로 라이브러리 파일이 파일 이름의 버전을 갖는 것처럼 수행하는 것입니다.

“일반 시스템을 손상시키지 않고 여러 버전의 라이브러리를 어떻게 설치할 수 있습니까?”

다시 한 번 시스템과 라이브러리에 따라 다릅니다. sudo make altinstall당신을 위해 버전 이름을 만들 것입니다. 라이브러리 파일은 일반적으로 자체 버전입니다. 그러나 명심하십시오. 버전은 종종 “정규화 된”이름에 대한 심볼릭 링크를 생성하므로 문제가 발생할 수 있습니다.

“패키지를 사용하여 관리되는 시스템에 소스에서 제공하는 것을 설치하는 경우 가장 깨끗한 방법은 무엇입니까?”

./configure에서 –prefix 매개 변수를 사용하고 어딘가에 배치 /opt하는 것이 좋습니다.

면책 조항 : 나는 결코 전문가는 아니지만 cmd 라인 (슬랙웨어, CentOS, redhat, 우분투, 기타 및 OS X) 에서 5 년 이상 Linux를 사용해 왔습니다 .


답변

귀하의 질문에 약간의 대답을하기 위해 언젠가 설치 한 라이브러리와 버전을 확인하는 좋은 방법을 찾았습니다 (Linux Debian에 있으므로 다른 버전에서도 작동합니다).

dpkg --list

다음과 같은 출력이있는 긴 목록을 가져와야합니다.

ii  libssl0.9.8    0.9.8c-4etch5  SSL shared libraries
ii  libssp0        4.1.1-21       GCC stack smashing protection library
ii  libstdc++5     3.3.6-15       The GNU Standard C++ Library v3
ii  libstdc++5-3.3 3.3.6-15       The GNU Standard C++ Library v3 (development
ii  libstdc++6     4.1.1-21       The GNU Standard C++ Library v3


답변

사이먼,

1.) ./configure –help는 많은 양의 정보를 제공합니다. 나는 그것을 확인하는 것이 좋습니다. 일반적으로 정적 / 동적 링크 라이브러리를 컴파일 할 수있는 옵션이 있습니다.

2.) 라이브러리는 동적 링커 경로에 있습니다. 이것은 보통 /etc/ld.so.conf에 설정됩니다. 링커는 처음 찾은 것과 일치하는 PATH 환경 변수와 같은 적절한 라이브러리를 검색합니다.

3.) 일반적으로 라이브러리 버전이 변경되면 모든 것을 다시 컴파일해야하므로 문제가 발생합니다. 일부 검색을 수행하면 정적으로 연결하는 것이 좋지 않은 이유가 있습니다. 나는 그렇게 오랫동안 그것을하지 않았습니다. 정말로 여기에서 설명 할 수 없습니다.

4.) 이것은 약간 어렵다. 라이브러리 경로는 반드시 확인해야합니다. 라이브러리에는 일반적으로 설치된 버전에 대한 심볼릭 링크가 있습니다.

예 : libssh2.so.1-> libssh2.so.1.0.0

일반적으로 사람들은 자신의 데비안 패키지를 롤링하거나 다른 기술을 사용하여 설치 한 라이브러리와 프로그램을 관리합니다. 나는 매우 간단한 stow ( http://www.gnu.org/software/stow/ )를 사용하여 설치된 소프트웨어를 관리하고 심볼릭 링크를 사용하여 라이브러리를 설치합니다. deb / rpm 패키지를 빌드 / 설치 / 테스트 할 필요가 없기 때문에 더 쉽습니다.

5.) 여러 버전의 라이브러리를 라이브러리 디렉토리에 정상적으로 설치할 수 있습니다. 실행 파일에 연결된 라이브러리는 연결된 버전에 연결된 상태로 유지됩니다. 실행 파일에서 ldd를 실행하면 실행 파일이 연결된 라이브러리가 표시됩니다.

6.) 앞서 언급 한 것처럼, 자신의 데비안 꾸러미를 굴 리거나 stow를 사용하는 것이 아마도 가장 깨끗한 해결책 일 것입니다.

7.) 나는 실제로 Mac OSX를 말할 수는 없지만 Linux의 경우 배포판의 패키징 시스템이 가장 좋습니다.

8.) ldd를 사용하고 어떤 버전과 어떤 버전이 연결되어 있는지 또는 어떤 라이브러리가 실행 파일과 연결되어 있지 않은지 알아 내면 많은 좌절이 해결 될 것입니다. pkg-config는 그것을 사용하는 소프트웨어에만 도움이 될 것입니다. 요즘 인기가 있지만 기본 autotools 빌드 시스템의 일부는 아닙니다.