Changing the CHOST variable/ko

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

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

There are certain situations where changing the CHOST is inevitable, e.g. if you want to upgrade to glibc 2.4 which only supports nptl and you find out that your CHOST is i386, which makes it impossible to use nptl. In this case, you don't have a lot of options, and changing CHOST is one of them.

Even if following these instructions, problems may arise, so please make sure you read and execute them very carefully. In this example the CHOST will be changed from i386 to i686, if you do another change, please change the commands accordingly.

꾸러미 빌드
CHOST 값 바꾸기를 시작하려면, 파일을 편집하여 여러분이 필요에 맞춰 CHOST 값을 바꾸십시오. 다음 순서를 통해 다음 꾸러미를 다시 빌드하십시오:

동작 확인
Now it is time to make sure that your  and   settings are sane and you do not have any leftovers in.

와  출력은 다음과 같아야 합니다(gcc 버전과 CHOST 값에 따라 다를 수 있으며, 여기는 GCC 4.1.1과 i686에 해당합니다):

Next, check to see if there are references to the old CHOST in :

Before deleting the file, let's check for files with the updated CHOST:

This one looks good as there should always be only one file for  in  (05gcc in this example), so let's delete the one with the wrong references:

The same also applies to  - if there's an extra one, see which is the outdated one and delete it. Next, check your

That one looks good, those two files actually should be there. Time to move on to the gcc directory.

and are fine, but  is another leftover that needs removal.

Now run the following commands to update your environment:

Then verify everything is fixed:

If you still find something, you must have missed some file, try to track it down before going on.

Finishing The Change
Now it is necessary to re-emerge  and run. Make sure to use the correct gcc version (your current one, 4.1.1 here, and the old architecture, i386 here). Replace $CHOST with your new CHOST, and  with your gcc version. This example assumes a CHOST of i686.

You may want to rebuild all your packages:

Now, in theory it should not be necessary to do so, but it can not be 100% guaranteed that this is actually the case. If you do not recompile the world target, I have been told at least some packages need recompiling, so you should do:

All packages using perl install to the CHOST directory and hence need remerging. In case you haven't installed , you will need to install   first.

If you encounter other packages that need recompiling, please let the author of this document know.

Common problems
When upgrading from gcc 3.3 to 4.1 at the same time as changing the CHOST (please don't do that anyway), a couple of users reported broken packages that need recompiling, such as groff and courier:

Error messsage

This happens because during the upgrade, the CHOST doesn't exactly match CTARGET and the compiler assumes cross-compiling. As a consequence, LDPATH isn't inserted into, resulting in this error.

Please see our gcc upgrade guide for what needs to be rebuilt after a gcc upgrade.

In some rare cases, this can break old versions of python, too. This may be fixed by adding (change accordingly to your old chost and gcc version) to , running   and then. However, as you can see, you really should avoid running into this problem - don't change CHOST and your gcc version at the same time.

Feedback
That should be all, feedback (both if it worked, failed or other problems were encountered) is welcome, please send an email to or post to this forums thread. Much in this howto comes from vapier, thanks for your help!

Acknowledgements
We would like to thank the following authors and editors for their contributions to this guide:


 * Wernfried Haas
 * Mike Frysinger
 * Chris White