크로스컴파일 환경 구축하기 - Monaca님의 글
개발 tool은 신뢰할 수 있어야 한다.
Embedded Linux System을 개발하는데, 마주치는 bug는
단순히 build가 되는 조합만 찾아서 build하면 ToolChain을 쓸 수 있는 것이 아니다.
그 다음에 반드시 해야 하는 것은 ToolChain에 대한 검증이다.
GNU toolchain에서는 이것을 regression test라고 부른다. 이 test는 많은 항목으로 이루어져 있고, 결과는 성공, 실패, 예상한 실패, 예상하지 못한 실패에 대한 항목 숫자로 나온다. (물론 실패에 대한 log도 제공한다.)
이 regression test는 native toolchain은 검증하기 쉽다. test tool을 설치하고 돌리면 그만이다. 그런데, cross toolchain은 그게 안된다. 각 file를 compile해서 해당 target에 돌린다음 그 결과를 봐야 하기 때문이다. 2만 항목이 넘는 것을 전부 수동으로 돌릴 수 없다. 따라서, 해당 tool에 대한 약간의 hacking과 host system 준비, NFS가 가능한 target board 환경이면 하루정도 꼬박 돌리면 결과를 볼 수 있다.
그리고, 그 결과를 분석해야 한다. 특히, 예상하지 못하게 성공하거나 실패한 항목에 대한 대비를 세워야 한다. 그 항목이 자주 쓰이는가, 관련 patch는 존재하는가, 그것을 피하는 방법은 있는지. patch가 있다면 patch해서 build한 다음에 문제는 없는지, 다른 부정적 효과는 없는지. 다시 regression test를 돌려봐야 한다.
그리고, gcc mailing list를 계속 monitor해서 현재 쓰고 있는 toolchain 조합에 보고된 문제가 없는지 확인해야 한다. 그 문제가 단순하게 정리가 되면 다음 gcc release에 test 항목으로 추가된다.
위 방법대로 하면 약 10개정도 내외의 bug를 지닌 ToolChain이 나온다. 남아 있는 bug들은 잘 쓰이지 않는 재현경로를 사용해서 발생하는 것들이다. 정석대로라면 toolchain에 README.BUG와 같은 file을 만들어서 해당 내용 및 재현방법을 기술해야 한다. 이에 대해서 피할 수 있는 방법까지 담고 있으면 더 좋다.
하지만, 그런 내용을 담은 file을 같이 배포하는 SDK를 보지 못했다.
결국 이 모든 악몽에서 벗어나는 방법은 검증된 ToolChain을 쓰는 것이다. 다음과 같은 방법으로 입수가 가능하다.
개발 tool은 신뢰할 수 있어야 한다.
Embedded Linux System을 개발하는데, 마주치는 bug는
1. CPU or Chip의 bug
2. H/W 설계 bug
3. OS bug
4. Application bug
5. 개발자의 오타
6. 시나리오 부재 또는 오류
이들과 싸워야 하는 programmer에게 gcc와 같은 기본적인 toolchain에 있는 버그는 악몽과도 같다.2. H/W 설계 bug
3. OS bug
4. Application bug
5. 개발자의 오타
6. 시나리오 부재 또는 오류
단순히 build가 되는 조합만 찾아서 build하면 ToolChain을 쓸 수 있는 것이 아니다.
그 다음에 반드시 해야 하는 것은 ToolChain에 대한 검증이다.
GNU toolchain에서는 이것을 regression test라고 부른다. 이 test는 많은 항목으로 이루어져 있고, 결과는 성공, 실패, 예상한 실패, 예상하지 못한 실패에 대한 항목 숫자로 나온다. (물론 실패에 대한 log도 제공한다.)
이 regression test는 native toolchain은 검증하기 쉽다. test tool을 설치하고 돌리면 그만이다. 그런데, cross toolchain은 그게 안된다. 각 file를 compile해서 해당 target에 돌린다음 그 결과를 봐야 하기 때문이다. 2만 항목이 넘는 것을 전부 수동으로 돌릴 수 없다. 따라서, 해당 tool에 대한 약간의 hacking과 host system 준비, NFS가 가능한 target board 환경이면 하루정도 꼬박 돌리면 결과를 볼 수 있다.
그리고, 그 결과를 분석해야 한다. 특히, 예상하지 못하게 성공하거나 실패한 항목에 대한 대비를 세워야 한다. 그 항목이 자주 쓰이는가, 관련 patch는 존재하는가, 그것을 피하는 방법은 있는지. patch가 있다면 patch해서 build한 다음에 문제는 없는지, 다른 부정적 효과는 없는지. 다시 regression test를 돌려봐야 한다.
그리고, gcc mailing list를 계속 monitor해서 현재 쓰고 있는 toolchain 조합에 보고된 문제가 없는지 확인해야 한다. 그 문제가 단순하게 정리가 되면 다음 gcc release에 test 항목으로 추가된다.
위 방법대로 하면 약 10개정도 내외의 bug를 지닌 ToolChain이 나온다. 남아 있는 bug들은 잘 쓰이지 않는 재현경로를 사용해서 발생하는 것들이다. 정석대로라면 toolchain에 README.BUG와 같은 file을 만들어서 해당 내용 및 재현방법을 기술해야 한다. 이에 대해서 피할 수 있는 방법까지 담고 있으면 더 좋다.
하지만, 그런 내용을 담은 file을 같이 배포하는 SDK를 보지 못했다.
결국 이 모든 악몽에서 벗어나는 방법은 검증된 ToolChain을 쓰는 것이다. 다음과 같은 방법으로 입수가 가능하다.
가. 상용으로 제공되는 것을 사는 경우, 비용은 약간 들지만 한두번 ToolChain Bug에 대한 경험을 가지고 있다면 상쇄할만하다. 특히 2~3년씩이나 오래 쓰는 경우, 기꺼이 치룰만하다.
나. 학생이거나 시험삼아 사용하는 경우, http://kegel.com/crosstool/ 와 같은 site에서 제공하는 ToolChain이 쓸만하다. 그들은 여러 version에 대한 (build 가능한) 조합을 제공하고, 조합한 결과에 대한 test 결과도 제공한다. 대개 toolchain의 bug는 잘 알려지지 않은 방법을 사용하는 경우에 발생하고, 약간의 위험을 감수할 만하다면 쓸만한다. 더우기 스스로 toolchain을 build해보는 즐거움도 맛볼 수 있다.
다. 몇몇 ToolChain 전문업체의 web site에 들어가서 download 받을 수 있다. 그들이 제공하는 ToolChain의 품질은 믿을만하고, 약간의 개인정보 (이름, e-mail과 같은)를 제공하고 받을 수 있다. 단지, 최신 CPU에 제공되는 새로운 instruction이나 최신 s/w version에서 제공하는 최적화 기능을 쓰지 못한다는 것은 감수해야 하지만. :-)
