[완료] gentoo - emerge busybox error

var/tmp/portage/sys-apps/busybox-1.4.1-r2/work/busybox-1.4.1 ...
 SPLIT   include/autoconf.h -> include/config/*
 GEN     include/bbconfigopts.h
 HOSTCC  applets/usage
 LD      archival/built-in.o
/bin/sh: i686-pc-linux-gnu-ar: command not found
 CC      applets/busybox.o
/bin/sh: i686-pc-linux-gnu-gcc: command not found
make[1]: *** [archival/built-in.o] Ошибка 127
make: *** [archival] Ошибка 2

말씀하신 링크에서 처럼 발생하는 문제가 원인이면..
경험상 미니멀CD 보다는 stage3을 선택했을때 사용자가 설정한 CHOST와 stage3에 들어있는 gcc+binutils와의 차이로 인해 문제가 발생하는 경우가 많았습니다. ar이라면 binutils 일테니, binutils만 다시 빌드해줘도 될법하군요 ;)

그런데, busybox만 그런걸 보면 뭔가 이상하긴 이상하네요; 언급해주신 멜링에서도 binutils를 다시 빌드해서 문제를 해결했다.. 라는 부분이 있긴 합니다만. 역시 젠투의 세계는 ~(_~_)~

저 같은 경우에는..

여하간 "x86" stage3의 타르볼을 풀고 이것저것 해주었을 때(/etc/make.profile 링크의 재설정, make.conf 작성하고 emerge --sync 날려서 포티지 동기화하는것 포함..)

작성한 CHOST="i686-pc-linux-gnu" 값이 이런 형태임에 반해
# ls /usr/i<TAB 완성> 을 했을 때 i386-pc-linux-gnu 또는 뭐 .. 여하간 현재의 CHOST와 차이가 있다..면, emerge world를 하기전에 (업데이트가 필요하면 glibc먼저, 이미 최신이면 상관없습니다)-gcc-binutils 를 우선적으로 빌드합니다.

물론, 슬롯이 달라서 새로 빌드를 하더라도 이전 버전이 없어지지 않는 경우도 있으니..
gcc 빌드 이후에는 "gcc-config -l" 로 현재 지정된 gcc가 자신이 지정했던 CHOST값과 원하는 버전으로 된 프로파일인지 확인하고,
(다르다면 "gcc-config [자신의CHOST]-[gcc버전]" 형태로 된 프로파일명을 입력해서 맞추고..)
binutils를 컴파일한 후에 역시 "binutils-config -l" 로 맞춰준다음
그런 다음 stage에 기본으로 들어가있던 binutils / gcc가 없어지지 않았으면 emerge -C 로 날려버립니다.

젠투에서 CHOST 값에 직접적인 영향을 받는 패키지가 gcc/binutils/perl 정도를 꼽을 수 있기 때문에, CHOST가 부득이하게 변경되면(라곤해도 최초설치때가 전부일텝니다만) 다른것을 업데이트 하기전에 이들을 최우선적으로 리빌드하는 습관을 가졌습니다.

논외의 이야기지만, sys-libs/db 같이 각 버전별 슬롯이 많이 잡혀있어 이버전 저버전 그버전 깔려있는 경우에도 최상위버전 빼놓고는 나머지는 -C 로 날려주고 revdep-rebuild 한방 쌔워서 최상위버전에 맞춰주는 형식으로, 패키지를 정리정돈(?) 하기도 합니다.

가끔씩 revdep-rebuild가 미친관계로 db 옛날버전을 깔려고 시도하면 취소해주고,
"equery depends db"로 의존성있는 애들을 찾아준 다음에 하나씩 리빌드 하기도 합니다.
(너무 삽스러운가요-_-;)

----
안드로메다는 이미 개념만으로도 빅뱅직전.