Distcc/Cross-Compiling/ko

이 안내서에서는 distcc에서의 다른 프로세서 아키텍처간 크로스컴파일 설정 방법을 보여줍니다.

도입부
는 네트워크에 연결한 다양한 컴퓨터에게 덩치가 큰 프로그램을 컴파일하도록 일감을 공유하는 도구입니다. 같은 프로세서 아키텍처로 만들어진 같은 툴체인을 네트워크에 연결한 여러대의 머신이 사용하면  설정을 따로 할 필요가 없습니다. 다만 각기 다른 아키텍처를 지닌 다른 컴퓨터로 컴파일해야 한다면 어떻게 해야 할까요? 이 안내서에서는 각기 다른 아키텍처에 대해 로 컴파일하는 방법을 알려드리도록 하겠습니다.

필요한 유틸리티 이머지
First, you will need to emerge  on all the machines that will be involved in the compiling process. is a tool that makes building cross-architecture toolchains easy. It was originally written by Joshua Kinard and was re-written from the ground up by Mike Frysinger. Its usage is straightforward:  will build a full cross-toolchain targetting the Sparc architecture. This includes binutils, gcc, glibc, and linux-headers. If you need more help, try running. Obviously, you will need to emerge the proper cross-toolchain on all the helper boxes.

Next, you will need to emerge  on all the machines that will be involved in the process. This includes the box that will run emerge and the boxes with the cross-compilers. Please see the Gentoo Distcc Documentation for more information on setting up and using.

인텔 x86 하위 아키텍처
If you are cross-compiling between different subarchitectures for Intel x86 (e.g. i586 and i686), you must still build a full cross-toolchain for the desired CHOST, or else the compilation will fail. This is because i586 and i686 are actually different CHOSTs, despite the fact that they are both considered "x86." Please keep this in mind when you build your cross-toolchains. For example, if the target box is i586, this means that you must build i586 cross-toolchains on your i686 helper boxes.

스파크
를 실행하면 다음 오류중 하나로 실패합니다:

crossdev -t sparc를 실행할 때 나타나는 오류

여기서 문제가 있다면 다음 명령을 대신 사용하십시오:

올바르게 크로스컴파일 하도록 distcc 설정
In the default distcc setup, cross-compiling will not work properly. The problem is that many builds just call  instead of the full compiler name (e.g.   ). When this compile gets distributed to a distcc helper box, the native compiler gets called instead of your shiny new cross-compiler.

Fortunately, there is a workaround for this little problem. All it takes is a wrapper script and a few symlinks on the box that will be running. I'll use my Sparc box as an example. Wherever you see  below, you will want to insert your own CHOST (   for an AMD64 box, for example). When you first emerge distcc, the directory looks like this:

여러분이 처리하려는 명령입니다:

Next, we'll create the new script on this box. Fire up your favorite editor and create a file with the following text in it, then save it as. Remember to change the CHOST (in this case,  ) to the actual CHOST of the box that will be running the emerge.

새 래퍼 스크립트

다음 실행 스크립트를 만들고 적당한 심볼릭 링크를 만들도록 하겠습니다:

끝났다면 은 다음과 같은 모습을 띠게 됩니다:

축하합니다. 이제 (원하는 대로) 동작하도록 cross-distcc를 설정했습니다.

동작 원리
When  is called, it checks to see what it was called as (e.g.  ,   , etc.) When distcc then distributes the compile to a helper box, it passes along the name it was called as. The distcc daemon on the other helper box then looks for a binary with that same name. If it sees just , it will look for   , which is likely to be the native compiler on the helper box, if it is not the same architecture as the box running. When the full name of the compiler is sent (e.g.  ), there is no confusion.

감사문
이 안내서에 제공한 노고에 대해 다음 작성자와 편집자분들께 감사의 말을 전하고자 합니다:


 * Andrew Gaffney
 * Joshua Saddler