영어프랑스어스페인어

Ad


온웍스 파비콘

distcc - 클라우드 온라인

Ubuntu Online, Fedora Online, Windows 온라인 에뮬레이터 또는 MAC OS 온라인 에뮬레이터를 통해 OnWorks 무료 호스팅 공급자에서 distcc 실행

Ubuntu Online, Fedora Online, Windows 온라인 에뮬레이터 또는 MAC OS 온라인 에뮬레이터와 같은 여러 무료 온라인 워크스테이션 중 하나를 사용하여 OnWorks 무료 호스팅 공급자에서 실행할 수 있는 distcc 명령입니다.

프로그램:

이름


distcc - distcc-pump 확장이 있는 분산 C/C++/ObjC 컴파일러

개요


distcc [컴파일러 옵션]

distcc [컴파일러 옵션]

[컴파일러 옵션]

distcc [DISTCC 옵션]

기술


distcc는 네트워크의 여러 시스템에 C 코드 컴파일을 배포합니다. distcc
항상 로컬 컴파일과 동일한 결과를 생성해야 하며 설치가 간단하고
사용하며 종종 로컬 컴파일보다 훨씬 빠릅니다.

이 버전은 일반 distcc와 펌프 모드 또는
distcc-펌프.

각 작업에 대해 일반 모드의 distcc는 전처리된 전체 소스 코드를 전송하고
클라이언트에서 컴파일 서버로 네트워크를 통해 컴파일러 인수. 펌프에서
모드에서 distcc는 소스 코드와 재귀적으로 포함된 헤더 파일을 보냅니다.
기본 시스템 헤더 디렉토리에서) 전처리와 컴파일이 모두
컴파일 서버에서 발생할 수 있습니다. 이렇게 하면 다음을 통해 편집 전달 속도가 빨라집니다.
일반 distcc에 비해 최대 XNUMX배까지.

컴파일은 일반적으로 개발자의 워크스테이션인 클라이언트 시스템에 의해 구동됩니다.
또는 노트북. distcc 클라이언트는 전처리기(만약
distcc의 펌프 모드는 사용되지 않음), 링커 및 빌드 프로세스의 다른 단계. 어느
다수의 자원 봉사 기계가 컴파일 서버 역할을 하고 클라이언트가
프로그램을 실행하여 distccd(1) 필요에 따라 데몬, C 컴파일러 및 어셈블러.

distcc는 TCP 소켓(기본적으로 포트 3632) 또는 터널을 통해 실행될 수 있습니다.
다음과 같은 명령 SSH(1). TCP 연결의 경우 자원 봉사자는 다음을 실행해야 합니다. distccd(1) 데몬
직접 또는 inetd에서. SSH 연결의 경우 distccd를 설치해야 하지만
지원 연결을 듣고 있습니다.

TCP 연결은 사용자가 없기 때문에 보안 네트워크에서만 사용해야 합니다.
소스 또는 개체 코드의 인증 또는 보호. SSH 연결은 일반적으로 25%입니다.
크게 다를 수 있지만 암호화를 위한 프로세서 오버헤드로 인해 속도가 느림
CPU, 네트워크 및 구축 중인 프로그램에 따라 다릅니다.

distcc는 GNU Make와 함께 사용하기 위한 것입니다. -j 여러 컴파일러를 실행하는 옵션
동시에 처리합니다. distcc는 작업을 로컬 및 원격 CPU 모두에 분산시킵니다.
distcc는 네트워크를 통해 대부분의 작업을 배포할 수 있기 때문에 더 높은
로컬 빌드보다 동시성 수준을 사용할 수 있습니다. 일반적으로, -j 가치
사용 가능한 총 서버 CPU 수의 약 두 배로 설정해야 하지만
클라이언트 제한. 이 설정은 차단되는 작업의 최대 인터리빙을 허용합니다.
디스크 또는 네트워크 IO를 기다리는 중입니다. distcc는 다른 빌드 컨트롤과도 작동할 수 있습니다.
유사한 동시성 설정을 조정해야 하는 SCons와 같은 도구.

XNUMXD덴탈의 -j 특히 큰 값에 대한 설정 -제이, CPU 부하를 고려해야 합니다.
클라이언트. 클라이언트 부하를 줄이기 위해 추가 조치가 필요할 수 있습니다. 예를 들어,
동시 연결은 보조 잠금을 사용하여 심각하게 축소되어야 합니다. 의 효과
혼합 코드를 빌드할 때 Java 컴파일과 같은 기타 빌드 활동은
존경받는. 그만큼 --localslots_cpp 매개변수는 기본적으로 16으로 설정됩니다.
일반 distcc(비펌프) 모드에서 전처리를 수행하는 동시 프로세스 수.
따라서 더 큰 -j 단일 CPU 클라이언트를 오버로드하지 않고 16보다 큰 값을 사용할 수 있습니다.
전처리 때문에. 이러한 큰 값은 그렇지 않은 빌드 부분의 속도를 높일 수 있습니다.
C 컴파일을 포함하지만 일반 모드에서 distcc 효율성에 유용하지 않을 수 있습니다.

대조적으로, 펌프 모드를 사용하고 40개의 서버라고 하면 -j80 또는 더 클 수 있습니다
단일 CPU 클라이언트에도 적합합니다.

모든 시스템에 동일한 컴파일러 버전을 설치하는 것이 좋습니다.
빌드에 참여합니다. 호환되지 않는 컴파일러는 알 수 없는 컴파일 또는 링크를 유발할 수 있습니다.
실패.

빠른 시작


1 각 머신에 대해 distcc를 다운로드하고 압축을 풀고 설치합니다.

2 각 서버에서 다음을 실행합니다. distccd --악마--허용하다 제한 옵션
액세스 할 수 있습니다.

3 환경에 서버 이름을 입력합니다.
$ export DISTCC_HOSTS='localhost 빨간색 녹색 파란색'

4 빌드!
$ make -j8 CC=distcc

빠른 시작 위한 DISTCC 펌프 모드


위와 같이 진행하되 3단계에서 원격 호스트가
사전 처리 및 네트워크를 통해 전송된 파일을 압축해야 합니다.

$ export DISTCC_HOSTS='--localhost red,cpp,lzo green,cpp,lzo 무작위화
블루,cpp,lzo'

XNUMXD덴탈의 --무작위화 옵션은 컴파일 서버의 균일한 사용을 강제합니다. 당신이 얻을 동안
몇 대의 서버만 있는 distcc의 펌프 모드에서 일부 이점을 얻으면 이점이 증가합니다.
더 많은 서버 CPU(최대 수백 개!) 펌프 명령 내에서 빌드를 래핑합니다.
여기서는 10개의 서버를 가정합니다.

$ distcc-펌프 만들기 -j20 CC=distcc

주문 제작 PLAIN (비 펌프) DISTCC WORKS


distcc는 컴파일러와 어셈블러를 원격으로만 실행합니다. 일반 distcc를 사용하면
전처리기는 다양한 헤더 파일에 액세스해야 하기 때문에 항상 로컬에서 실행되어야 합니다.
지원자에게 없을 수도 있고 동일하지 않을 수도 있는 로컬 머신. 그만큼
링커도 마찬가지로 라이브러리와 개체 파일을 검사해야 하므로 로컬에서 실행해야 합니다.

컴파일러와 어셈블러는 단일 입력 파일(전처리된 소스)만 사용하고
단일 출력(객체 파일)을 생성합니다. distcc는 이 두 파일을
따라서 컴파일러/어셈블러를 원격으로 실행할 수 있습니다.

다행스럽게도 전처리기를 실행하는 대부분의 프로그램의 경우 상대적으로 비용이 저렴합니다.
링커는 상대적으로 드물게 호출되므로 대부분의 작업을 분산시킬 수 있습니다.

distcc는 명령줄을 검사하여 이러한 단계 중 어떤 단계가 호출되고 있는지 확인합니다.
작업을 배포할 수 있는지 여부.

주문 제작 DISTCC 펌프 모드 WORKS


펌프 모드에서 distcc는 전처리기를 원격으로도 실행합니다. 이를 위해 전처리기는 다음을 수행해야 합니다.
로컬에서 실행 중이었다면 액세스했을 모든 파일에 액세스할 수 있습니다. ~ 안에
따라서 펌프 모드에서 distcc는 다음을 제외하고 재귀적으로 포함된 모든 헤더를 수집합니다.
기본 시스템 헤더이며 소스 파일과 함께
컴파일 서버.

distcc-pump 모드에서 서버는 모든 소스 파일 세트를 임시로 압축을 풉니다.
디렉토리에는 파일 시스템의 일부를 미러링하는 디렉토리 트리가 포함되어 있습니다.
심볼릭 링크를 포함한 전처리와 관련이 있습니다.

그런 다음 컴파일러는 다음에 해당하는 임시 디렉토리의 경로에서 실행됩니다.
클라이언트의 현재 작업 디렉토리. 수백 개의 파일을 찾아 전송하기 위해
종종 단일 컴파일의 일부인 펌프 모드는 증분 포함을 사용합니다.
분석 알고리즘. 인클루드 서버는 이것을 구현하는 Python 프로그램입니다.
연산. distcc-pump 명령은 포함 서버를 시작하여 빌드 전체에서
distcc 명령으로 포함 쿼리에 응답할 수 있습니다.

포함 서버는 매크로 언어의 정적 분석을 사용하여 조건부를 처리합니다.
컴파일 및 계산 포함. 주어진 헤더 파일이 있을 때 속성을 사용합니다.
포함에 대해 이미 분석된 경우 모든 포함이 있는 경우 다시 분석할 필요가 없습니다.
옵션(-I's)은 변경되지 않습니다(다른 조건과 함께).

대규모 빌드의 경우 헤더 파일이 각각 평균 ​​수백 번 포함됩니다. 와 함께
distcc-pump 모드 이러한 각 파일은 대신 몇 번, 아마도 한 번만 분석됩니다.
수백번의 전처리 과정을 거치게 됩니다. 또한 각 소스 또는 헤더 파일은 이제
인클루드 서버가 압축 파일을 메모하기 때문에 한 번만 압축됩니다. 로
결과적으로 편집을 준비하는 데 사용되는 시간이 최대 XNUMX배까지 줄어들 수 있습니다.
일반 distcc의 전처리를 통해.

펌프 모드의 distcc는 최대 약 XNUMX배 더 빠르게 파일을 푸시할 수 있기 때문에
일반 distcc 모드에 비해 대규모 빌드의 경우 속도가 3배 이상 증가할 수 있습니다.

제한 사항 위한 펌프 모드


펌프 모드를 사용하려면 클라이언트와 서버 모두 distcc 릴리스 3.0 이상을 사용해야 합니다.
distccd(각각).

distc-pump 모드의 증분 포함 분석은 기본 가정에 기반합니다.
소스 및 헤더 파일은 빌드 프로세스 중에 변경되지 않습니다. 몇 가지 복잡한 빌드
Linux 커널 2.6과 같은 시스템은 이 요구 사항을 완전히 충족하지 못합니다. 에게
이러한 문제 및 포함의 절대 파일 경로와 같은 기타 코너 케이스를 극복하려면 다음을 참조하십시오.
전에, 포함_서버(1) man 페이지.

또 다른 중요한 가정은 모든 시스템의 포함 구성이 다음과 같아야 한다는 것입니다.
동일한. 따라서 기본 시스템 경로 아래의 헤더는 모든 서버에서 동일해야 합니다.
그리고 모든 클라이언트. 표준 GNU 컴파일러 설치를 사용하는 경우 이 요구 사항
헤더 파일이 설치된 모든 라이브러리에 적용됩니다. / usr / include or
/usr/로컬/포함/. 소프트웨어 패키지를 설치하면 종종 추가
헤더 파일은 둘 중 하나의 하위 디렉토리에 배치됩니다.

이 가정이 유지되지 않으면 distcc-pump로 빌드를 중단할 수 있습니다.
경고 없이 잘못된 결과를 얻을 수 있습니다. 현재 이 상태가 아니다.
확인되었으며 이 문제를 해결하기 위한 TODO 목록에 있습니다.

포함 구성이 동일하다는 것을 보장하는 쉬운 방법은 교차
의 디렉토리로 제한된 기본 시스템 검색 경로를 정의하는 컴파일러
컴파일러 설치.

을 참조 포함_서버(1) 위반 증상 및 원인에 대한 자세한 내용은 설명서
distcc-pump 모드 가정.

OPTION 개요


distcc에 전달된 대부분의 옵션은 컴파일러 옵션으로 해석됩니다. 다음 옵션
distcc 자체에서 이해합니다. 이러한 옵션 중 하나라도 지정되면 distcc는
컴파일러를 호출합니다.

--도움 요약 지침을 표시합니다.

--번역
distcc 클라이언트 버전을 표시합니다.

--쇼 호스트
distcc가 사용할 호스트 목록을 표시합니다. 호스트 사양 섹션을 참조하십시오.

--스캔 포함
distcc가 원격 시스템으로 보낼 파일 목록을 다음과 같이 표시합니다.
포함 서버에 의해 계산됩니다. 이것은 다음의 보수적인 (과도한) 근사입니다.
C 컴파일러가 읽을 수 있는 파일. 이 옵션은 펌프 모드에서만 작동합니다.
계산 방법에 대한 자세한 내용은 "Distcc-pump 모드 작동 방식" 섹션을 참조하십시오.

목록 출력 distcc --스캔 포함 한 줄에 하나의 항목이 포함됩니다. 각
라인에는 범주와 경로가 포함됩니다. 카테고리는 FILE, SYMLINK,
디렉토리 또는 SYSTEMDIR:

FILE distcc 서버로 전송될 소스 파일 또는 헤더 파일을 나타냅니다.
숙주.

심볼릭 링크 distcc 서버 호스트로 전송될 심볼릭 링크를 나타냅니다.

디렉토리 소스를 컴파일하기 위해 필요할 수 있는 디렉토리를 나타냅니다.
파일. 예를 들어 "foo"라는 디렉토리가 필요할 수 있습니다.
양식 #include "foo/../bar.h". 이러한 디렉토리는 distcc에 생성됩니다.
서버 호스트.

시스템디렉터리 시스템 포함 디렉토리, 즉 시스템에 있는 디렉토리를 나타냅니다.
컴파일러의 기본 포함 경로(예: "/ usr / include"; 그러한 디렉토리는
distcc 서버 호스트에 있는 것으로 가정하므로
distcc 서버 호스트.

-j 호스트 목록에서 계산된 대로 distcc의 동시성 수준을 표시합니다. 그것은
이 클라이언트가 모든 서버에 발행한 미결 작업의 최대 수입니다. 에 의해
기본값은 호스트 목록에 있는 호스트 수의 XNUMX배입니다.
/LIMIT 옵션이 호스트 목록에 사용되었습니다. 호스트 사양 섹션을 참조하십시오.

설치 DISTCC


서로 다른 상황에 맞게 distcc를 호출하는 세 가지 방법이 있습니다.

distcc는 호출을 가로채기 위해 실제 컴파일러의 이름으로 설치할 수 있습니다.
그것을 원격으로 실행하십시오. 이 "가장된" 컴파일러는 호환성이 가장 넓습니다.
기존 소스 트리와 함께 사용할 수 있으며 모두에 대해 distcc를 사용하려는 경우에 편리합니다.
편집. distcc가 사용되고 있다는 사실은 makefile에 투명합니다.

distcc는 "distcc cc -c hello.c"와 같이 컴파일러 명령줄 앞에 붙일 수 있습니다.
또는 CC="distcc gcc". 이는 distcc를 일부에만 사용하려는 경우에 편리합니다.
컴파일하거나 시도해 볼 수 있지만 일부 makefile에 문제가 발생할 수 있습니다.
$CC에 공백이 없다고 가정하는 libtool 버전.

마지막으로 distcc는 컴파일러로 직접 사용할 수 있습니다. "cc"는 항상
이 "암시적" 모드에서 실제 컴파일러의 이름입니다. 이것은 편리 할 수 ​​있습니다
"명시적" 모드가 작동하지 않지만 실제로 권장되지 않는 경우 대화식 사용
새로운 사용을 위해.

동시에 distcc를 호출하기 위해 두 가지 방법을 사용해서는 안 된다는 점을 기억하십시오. 만약 너라면
마스커레이드 디렉토리를 사용하고 있습니다. CC 및/또는 CXX를 변경하지 말고 디렉토리를 초기에 배치하십시오.
당신의 PATH에. 마스커레이드 디렉토리를 사용하지 않는 경우 CC를 변경하거나
및/또는 CXX, 또는 distcc를 명시적으로 호출하도록 메이크파일을 수정합니다.

추측


기본 아이디어는 이름의 링크를 포함하는 "마스커레이드 디렉토리"를 만드는 것입니다
distcc 바이너리에 대한 실제 컴파일러. 이 디렉토리는 PATH의 초기에 삽입되므로
컴파일러에 대한 호출이 차단되고 distcc가 대신 실행됩니다. 그런 다음 distcc가 제거합니다.
실제 컴파일러를 찾기 위해 PATH에서 자체.

예 :

# mkdir /usr/lib/distcc/bin
# CD /usr/lib/distcc/bin
# ln -s ../../../bin/distcc gcc
# ln -s ../../../bin/distcc 참조
# ln -s ../../../bin/distcc g++
# ln -s ../../../bin/distcc C++

그런 다음 distcc를 사용하려면 사용자는 /usr/lib/distcc/bin 디렉토리를 초기에 배치하기만 하면 됩니다.
PATH, DISTCC_HOSTS 또는 파일에 호스트 목록을 설정했습니다. distcc가 처리합니다.
휴식.

이 마스커레이드 디렉토리는 해당 디렉토리보다 앞선 PATH에 있어야 합니다.
동일한 이름의 실제 컴파일러를 포함하며,
이러한 컴파일러 호출(예: 또는 ld)은 디렉토리의 PATH에서도 찾아야 합니다.
distcc가 PATH를 사용하여 실제 컴파일러를 호출하기 때문에 masquerade 디렉토리 다음에
가장 무도회 디렉터리를 포함한 모든 디렉터리가 잘린 값입니다.

마스커레이드 모드에서 "재귀 오류"가 발생할 수 있습니다. 이는 distcc가
어떻게 든 실제 컴파일러가 아닌 자신을 다시 찾습니다. 이것은 당신이 두 가지를 가지고 있음을 나타낼 수 있습니다
두 개의 distcc 설치가 있기 때문일 수 있습니다.
다른 위치. 또한 "마스커레이드"와
"명시적" 작업.

링크 대신 쉘 스크립트를 사용하여 재귀 오류를 피할 수 있습니다. 예를 들어,
/usr/lib/distcc/bin 다음을 포함하는 cc 파일을 만듭니다.

#!/ 빈 / SH
distcc /usr/bin/gcc "$@"

이런 식으로 우리는 조사를 통해 실제 gcc를 찾아야 하는 distcc에 의존하지 않습니다.
PATH 변수. 대신 컴파일러 위치가 명시적으로 제공됩니다.

사용 DISTCC 세이프가드가 씨캐쉬


ccache는 컴파일 결과를 캐싱하여 소프트웨어 빌드 속도를 높이는 프로그램입니다.
ccache는 일반적으로 distcc보다 먼저 호출되므로 결과는 일반에서 검색됩니다.
은닉처. 특이한 makefile을 만들려면 몇 가지 실험이 필요할 수 있습니다.
모든 것이 함께 작동합니다.

가장 신뢰할 수 있는 방법은 설정하는 것입니다.

CCACHE_PREFIX="distcc"

이것은 ccache가 distcc를 실제 컴파일러 주변의 래퍼로 실행하도록 지시합니다. ccache는 여전히 사용
컴파일러 업그레이드를 감지하는 실제 컴파일러.

그런 다음 ccache는 마스커레이드 디렉토리를 사용하여 실행할 수 있습니다. or 설정하여

CC="캐시 gcc"

버전 2.2부터 ccache는 사전 처리된 소스에서 컴파일을 캐시하지 않으므로
distccd 또는 distcc에서 실행되는 경우 캐시 적중을 얻지 마십시오. 에서만 실행해야 합니다.
클라이언트 측과 distcc 이전에 사용할 수 있습니다.

distcc의 펌프 모드는 ccache와 호환되지 않습니다.

HOST 스펙


"호스트 목록"은 컴파일에 사용할 기계를 distcc에 알려줍니다. distcc는 순서대로
FBI 증오 범죄 보고서 $DISTCC_HOSTS 환경 변수, 사용자의 $DISTCC_DIR/호스트 파일 및
시스템 전체 호스트 파일. 호스트 목록을 찾을 수 없으면 distcc는 경고를 내보내고 컴파일합니다.
토지 상에서.

호스트 목록은 공백으로 구분된 호스트 사양 목록입니다. 가장 단순한
가장 일반적인 형식은 다음과 같은 호스트 이름입니다.

로컬 호스트 빨간 녹색 푸른

distcc는 목록의 시작 부분에 있는 호스트를 선호하므로 기계는 다음 위치에 나열되어야 합니다.
내림차순 속도. 특히 단일 컴파일만 실행할 수 있는 경우(예:
구성 스크립트에서와 같이) 나열된 첫 번째 시스템이 사용됩니다(그러나 --무작위화 아래).

전화 걸기 로컬 호스트 좋은 성능을 얻으려면 목록의 올바른 지점에 있는 것이 중요합니다.
작업을 로컬에서 실행하기 위한 오버헤드가 낮기 때문에 일반적으로 localhost가 첫 번째여야 합니다.
그러나 클라이언트가 로컬 작업을 실행할 수 있는 충분한 주기를 가지고 있고
distcc 클라이언트. 클라이언트가 자원봉사자보다 느리거나 자원봉사자가 많은 경우
그런 다음 고객은 나중에 목록에 포함되거나 전혀 포함되지 않아야 합니다. 일반적으로
규칙에서 클라이언트의 총 CPU 속도가 전체의 XNUMX/XNUMX 미만인 경우
클라이언트는 목록에서 제외되어야 합니다.

대규모 공유 빌드 클러스터와 단일 공유 호스트 파일이 있는 경우 위의 규칙
호스트 파일의 처음 몇 대의 시스템이 먼저 시도됩니다.
목록의 뒷부분에 있는 기계보다 더 바쁠 가능성이 높습니다. 이를 방지하려면 키워드를
--무작위화 호스트 목록에. 이로 인해 호스트 목록이 무작위화되어
대규모 빌드 클러스터의 경우 성능이 약간 향상됩니다.

두 개의 특수 호스트 이름이 있습니다. --localslots--localslots_cpp 에 유용한
로컬 시스템의 로드 조정. 그만큼 --localslots 호스트는 작업 수를 지정합니다.
로컬 컴퓨터에서 동시에 실행할 수 있는 원격으로 실행할 수 없습니다.
--localslots_cpp 로컬에서 병렬로 실행할 전처리기 수를 제어합니다.
기계. 이러한 값을 조정하면 성능을 향상시킬 수 있습니다. 대규모 프로젝트에 연결하는 데 시간이 걸릴 수 있습니다.
많은 양의 메모리. 원격으로 실행할 수 없는 병렬 링커 실행,
시스템을 강제로 교체할 수 있으며, 이로 인해 작업을 실행하는 것보다 성능이 저하됩니다.
스와핑 없는 시퀀스. 병렬 전처리기의 수를 올바르게 얻기
이제 로컬 시스템이 일부
로컬 리소스 사용을 측정하기 위한 메커니즘입니다.

마지막으로 호스트 항목이 있습니다.

성능은 프로젝트에 사용된 소스 및 메이크파일의 세부 정보에 따라 달라집니다.
기계 및 네트워크 속도. 호스트 목록에 대한 다양한 설정 실험
-j 요소는 성능을 향상시킬 수 있습니다.

구문은

DISTCC_HOSTS = 호스트 사양 ...
호스트 사양 = LOCAL_HOST | SSH_HOST | TCP_호스트 | OLDSTYLE_TCP_HOST
| 글로벌 옵션
| 제로컨프
LOCAL_HOST = 로컬 호스트[/LIMIT]
| --localslots=
| --localslots_cpp=
SSH_HOST = [사용자]@HOSTID[/LIMIT][:COMMAND][옵션]
TCP_HOST = HOSTID[:포트][/LIMIT][옵션]
OLDSTYLE_TCP_HOST = 호스트 ID[/LIMIT][:PORT][OPTIONS]
HOSTID = 호스트 이름 | IPv4 | IPV6
옵션 = ,옵션[옵션]
옵션 = lzo | cpp
GLOBAL_OPTION = --랜덤화
ZEROCONF = +zeroconf

다음은 구문의 몇 가지 개별 예입니다.

로컬 호스트
리터럴 단어 "localhost"는 특별히 컴파일을 유발하도록 해석됩니다.
로컬 시스템의 데몬으로 전달되지 않고 직접 실행됩니다. 당신이 할 경우
테스트를 위해 로컬 시스템의 데몬에 연결하려는 경우
컴퓨터의 IP 주소 또는 실제 호스트 이름. (이것은 더 느릴 것입니다.)

IPV6 다음과 같이 대괄호로 묶인 리터럴 IPv6 주소 [::1]

IPV4 다음과 같은 리터럴 IPv4 주소 10.0.0.1

호스트 이름
확인자를 사용하여 조회할 호스트 이름입니다.

:포트 기본값인 3632가 아닌 지정된 십진수 포트 번호에 연결합니다.

@HOSTID
TCP가 아닌 SSH를 통해 호스트에 연결합니다. SSH 연결에 대한 옵션은
자리를 잡다 ~ / .ssh / config

사용자@ 지정된 사용자 이름으로 SSH를 통해 호스트에 연결합니다.

:명령
SSH를 통해 연결하고 지정된 경로를 사용하여 distccd 서버를 찾습니다. 이것은
일반적으로 어떤 이유로 distccd를 디렉토리에 설치할 수 없는 경우에만 필요합니다.
SSH 연결을 위한 기본 PATH에 있습니다. "distccd:
SSH 모드에서 명령을 찾을 수 없습니다."

/한계 모든 호스트 사양에 소수점 제한을 추가하여 호스트 수를 제한할 수 있습니다.
이 클라이언트가 컴퓨터로 보낼 작업. 한도는 기본적으로 당 XNUMX개입니다.
호스트(로컬 호스트의 경우 XNUMX개), 그러나 서버에 의해 추가로 제한될 수 있습니다. 당신은해야
프로세서가 XNUMX개 이상인 서버의 경우에만 이 값을 늘리면 됩니다.

,이조 이 TCP 또는 SSH 호스트에 대해 LZO 압축을 활성화합니다.

,cpp 이 호스트에 대해 distcc-pump 모드를 활성화합니다. 참고: 빌드 명령은
include 서버를 시작하기 위한 distcc-pump 스크립트.

--무작위화
실행 전에 호스트 목록의 순서를 무작위로 지정합니다.

+zeroconf
선택권 is 가능 if distcc 였다 컴파일 아바 히 SUPPORT 사용 가능 at
구성 시간. 이 특별한 항목이 호스트 목록에 있으면 distcc는
Avahi Zeroconf DNS 서비스 검색(DNS-SD)을 사용하여 사용 가능한 distccd를 찾습니다.
로컬 네트워크의 서버. 이렇게 하면 호스트를 명시적으로 나열할 필요가 없습니다.
distcc 서버 머신의 이름 또는 IP 주소. distccd 서버는
distccd에 "--zeroconf" 옵션으로 시작되었습니다. 중요한 경고는
현재 구현에서 펌프 모드(",cpp") 및 압축(",lzo")은
zeroconf를 통해 찾은 호스트에는 절대 사용하지 마십시오.

다음은 몇 가지 가능성을 보여주는 예입니다.

로컬 호스트/2 @bigman/16:/opt/bin/distccd 오래된 기계:4200/1
# 카트 먼 is 아래 (down)
먼/3,lzo

주석은 호스트 사양에서 허용됩니다. 주석은 해시/파운드 기호(#)
그리고 줄 끝까지 달려갑니다.

목록의 호스트에 도달할 수 없는 경우 distcc는 경고를 표시하고 해당 호스트를 무시합니다.
약 XNUMX분.

압축


XNUMXD덴탈의 이조 호스트 옵션은 LZO 압축이 데이터 전송에 사용되어야 함을 지정합니다.
전처리된 소스, 개체 코드 및 오류 메시지를 포함합니다. 압축은 보통
100Mbps보다 느린 네트워크에서 경제적이지만 네트워크에 따라 결과가 다를 수 있습니다.
프로세서 및 소스 트리.

압축을 활성화하면 distcc 클라이언트와 서버가 더 많은 CPU 시간을 사용하지만
네트워크 트래픽. 추가된 CPU 시간은 펌프 모드에서 중요하지 않습니다. 압축
비율은 일반적으로 소스의 경우 4:1이고 개체 코드의 경우 2:1입니다.

압축을 사용하려면 클라이언트와 서버 모두 distcc 릴리스 2.9 이상을 사용해야 합니다.
서버 구성이 필요하지 않습니다. 서버는 항상 압축된 응답으로 응답합니다.
압축된 요청

펌프 모드에서는 서버에 lzo 호스트 옵션이 켜져 있어야 합니다.

검색 선택 경로


컴파일러 이름이 절대 경로인 경우 서버에 그대로 전달되고
컴파일러는 해당 디렉토리에서 실행됩니다. 예를 들어:

distcc /usr/local/bin/gcc-3.1415 -c 안녕하세요.c

컴파일러 이름이 절대적이지 않거나 정규화되지 않은 경우 distccd의 PATH가 검색됩니다.
distcc가 가장 디렉터리에서 실행될 때 컴파일러의 기본 이름만
사용된. 클라이언트의 PATH는 전처리기를 실행하는 데만 사용되며 클라이언트에 영향을 주지 않습니다.
서버의 경로.

시간 초과


distcc 클라이언트와 서버는 모두 네트워크를 통한 데이터 전송에 시간 초과를 부과합니다.
다운되었거나 연결할 수 없는 호스트를 감지하고 컴파일을 방지하기 위한 것입니다.
사용 중에 서버 연결이 끊기면 무기한 중단됩니다. 클라이언트 측 시간 초과인 경우
만료되면 작업이 로컬에서 다시 실행됩니다.

시간 제한은 현재 구성할 수 없습니다.

진단


로컬 또는 원격 컴파일러의 오류 메시지 또는 경고가 진단으로 전달됩니다.
클라이언트에서 출력.

distcc는 verbose 옵션이 사용될 때 광범위한 디버깅 정보를 제공할 수 있습니다. 이것
에 의해 통제된다. DISTCC_VERBOSE 클라이언트의 환경 변수 및 --말 수가 많은
서버에서 옵션. 문제 해결을 위해 클라이언트 및 서버 오류를 모두 검사하십시오.
메시지.

EXIT 코드


distcc의 종료 코드는 일반적으로 컴파일러의 종료 코드입니다. 성공적인 컴파일의 경우 XNUMX입니다.
그렇지 않으면 XNUMX이 아닙니다.

distcc는 소스의 구문 오류와 같은 "진정한" 오류를 구별합니다.
자원 봉사자와 연결하는 네트워킹 문제와 같은 "우발적인" 오류. 경우에
우발적 오류의 경우, distcc는 DISTCC_FALLBACK이 아닌 한 로컬에서 컴파일을 재시도합니다.
옵션이 비활성화되었습니다.

컴파일러가 신호와 함께 종료되면 distcc는 종료 코드 128과 신호를 반환합니다.
수.

distcc 내부 오류로 인해 100에서 127 사이의 종료 코드가 발생합니다. 특히

100 일반 distcc 실패.

101 잘못된 인수.

102 바인드 실패.

103 연결에 실패했습니다.

104 컴파일러가 충돌했습니다.

105 메모리가 부족합니다.

106 잘못된 호스트 사양

107 I/O 오류

108 잘림.

109 프로토콜 오류.

110 지정된 컴파일러가 원격 호스트에서 발견되지 않았습니다. $CC가 설정되어 있는지 확인
에 대한 검색 경로의 디렉토리에 설치되어 있는지 확인합니다.
distccd.

111 distcc에 대한 재귀 호출.

112 권한을 버리지 못했습니다.

113 네트워크 액세스가 거부되었습니다.

114 다른 프로세스에서 사용 중입니다.

115 그런 파일이 없습니다.

116 호스트가 정의되지 않았으며 폴백이 비활성화되었습니다.

118 시간 초과.

onworks.net 서비스를 사용하여 distcc 온라인 사용


무료 서버 및 워크스테이션

Windows 및 Linux 앱 다운로드

Linux 명령

Ad