Changing the CHOST variable/ko

이 문서는 시스템에 있는 CHOST 변수 값을 바꾸는 방법을 설명합니다.

CHOST 값을 바꾸는 일은 시스템 전체를 이상하게 꼬이게 할 수 있는 큰 문제입니다 - 그러니까 왜 그 대혼란을 야기할 문제가 안내서에 있냐고요?

CHOST 값을 어쩔 수 없이 바꿨을때 몇가지 상황이 발생하는데, 예컨대, nptl만 지원하는 glibc 2.4를 업그레이드 하려 하는데 CHOST 값을 nptl 사용이 불가능한 i386으로 설정한 경우를 찾을 때가 있습니다. 이 경우, 상당히 많은 옵션을 보유하지 않아, 이 옵션 중 CHOST 값을 바꿔야 합니다.

이 절차를 따르더라도 문제가 발생할 수 있으니, 매우 조심스럽게 읽고 실행에 옮겼는지 확인 하십시오. 이 경우 CHOST 값이 i386에서 i686 으로 바뀌며, 개인적인 상황에 따라 다른 값을 바꿨을 경우 그에 따라 명령도 바꿉니다.

Updating make.conf
To start out with the CHOST variable change, edit the file and add/change the CHOST value to suit the requirements.

Note that profiles provide a default setting for CHOST ; depending on the situation, it may be necessary to override it in or remove an override in. In any case, the important point is that the effective value changes.

Please note that if planning to use another value of CHOST than the profile default, the CHOST_${ABI} variable may need updating as well. It is possible to query the value of this variable of the currently set profile with the portageq tool:

If this value is equal to CHOST, it's good. Otherwise, override it as well, e.g.:

꾸러미 빌드
Rebuild the following packages in this order:

동작 확인
이제 와 설정이 온전한지 확인하고 에서 나머지 요소를 날릴 때입니다.

와 출력은 다음과 같아야 합니다:

다음, 이전 CHOST 변수 값을 에서 참조하는지 확인하십시오:

Here, binutils is fine - there is one file, and it only contains references to the new CHOST. For gcc, there is a file for both the new and the old CHOST value, so delete the old stale one:

이 같은 설정은 에도 적용합니다 - 추가 요소가 있을 경우 오래된 요소를 찾아 삭제하십시오. 다음 디렉터리를 확인하십시오:

보기 좋아보이는군요, 실제로 두 파일이 위치해 있습니다. 이제 디렉터리로 이동할 때입니다.

Time to move on to the directory.

와 은 괜찮지만 제거해야 할 가 남아있습니다.

이제 환경을 업데이트하려면 다음 명령을 실행하십시오:

모든 문제를 고쳤는지 확인하십시오:

값 바꾸기 끝내기
이제 를 다시 이머지하고 에 있는 를 실행해야 합니다. 올바른 gcc 버전을 사용중이며(현재 여기서는 4.1.1) 이전 아키텍처(i386)를 매개변수로 넘겼는지 확인하십시오. 값을 새 CHOST 값으로 바꾸고 를 현재 gcc 버전으로 바꾸십시오. 이 예제에서는 CHOST 값을 i686으로 설정했음을 가정합니다.

이제 모든 꾸러미를 다시 빌드할 수 있습니다:

In theory, it should not be necessary to do so, but it cannot be 100% guaranteed that this is actually the case. Alternatively, it is possible to manually rebuild all the known problematic packages:


 * multilib packages using CHOST prefixing or header wrapping,
 * Perl, Python and other tools that store configured compiler path.

Note that paths that do not apply to the current system may need removing from the above invocation.

다시 컴파일 해야 할 패키지가 아직도 몇개 있다면 이 문서를 작성한 저자에게 토론 페이지en 에서 알려주십시오.

일반적인 문제
Not so many anymore. Usually this just works, as long as no really exotic change is done. Make sure to not combine the CHOST change with other steps though. Some of the notes below are really old...

CHOST 값을 바꾼 후 GCC 3.3에서 4.1로 업그레이드 할 때(어쨌든 이렇게 하지 마십시오), 꽤 많은 사람이 와 같은 꾸러미가 깨져 다시 컴파일해야 한다고 보고했습니다:

이 일은 업그레이드 도중에 CHOST 값이 CTARGET 과 일치하지 않고, 컴파일러가 크로스컴파일하는걸로 간주하기 때문에 일어나는 일입니다. 결과적으로 LDPATH 값을 에 넣지 않아 이 오류가 나타납니다.

GCC 업그레이드 후 다시 빌드해야 할 꾸러미의 정보는 GCC 업그레이드 안내서를 참고하십시오.

어떤 드문 경우에는 오래된 버전의 파이선도 깰 수 있습니다. (이전 CHOST 값에 따라 바꾸십시오)를 에 추가하고 를 실행한 다음 를 실행하면 문제를 해결할 수 있습니다. 그러나 보신 바와 같이 이 문제에 직면하는걸 제대로 막아야 합니다. CHOST 값과 GCC 버전을 동시에 바꾸지 마십시오.

피드백
피드백(동작할 경우든, 실패했거나, 다른 문제가 있다면)은 모두 환영하니 이 포럼 스레드en 에 글을 남겨주십시오. 여기 안내서의 내용은 vapier가 알려주었습니다. 도움 감사합니다!