한 프로젝트에 서로 다른 컴파일러 사용
안녕하세요. 임베디드 SW쪽으로 입문한 초보 개발자입니다.
궁금한게 있어 혹시 전문가 분들의 경험/지식의 도움을 얻을 수 있을까 하여 글을 남깁니다.
외국회사랑 일을 하게 되었는데 컴파일러 문제로 오고 가다 결국 다른 컴파일러를 사용해서 개발하게될 것 같습니다.
우선 우리가 쓰는 컴파일러(Greenhills)랑 동일한 환경에서 해야한다고 처음에 언급을 해 두었는데, 그 회사에서 Greenhills에 알아본 결과 상업용으로는 trial 버전을 못 구한다고 어찌됬는 비용 문제로 본인들은 컴파일러를 구매할 순 없으니 자기네는 gcc를 써야한다고 연락이 왔는데요.
다른 컴파일러를 사용하여 각각 개발하게 되면 통합은 제가 하는데 그럼 그 때 복잡해진다고 안된다고 우리는 말하고 있는데 거기는 비용때문에 절대 안된다 입장이어서요...
저희 팀의 다른분들한테 물어봐도 이런식으로(gcc 컴파일러로 구현한 것을 greenhills에 옴기기)는 해 본 적 없을 뿐더러 컴파일러 종속적인 명령어나 헤더가 있기 때문에 에러가 많이 날거라고 하는데요. 한국 greenhills 총판에 물어봐도 이런건 해본적 없다고 잘 모르겠다고 하고.
혹시 A 컴파일러로 구현한 것을 B 컴파일러로 구현한 SW에 통합해보신 적 있는 분 계신가요? 아니면 비슷한 것이라도.. 이런 것이 가능한 일인지..
저희가 외국회사에서 받는 형식은 SW소스코드로 받습니다만 한 가지 파일에 대해서는 라이브러리로 받습니다.
그냥 무식한 제 생각엔 소스코드가 오니까 코드라인들을 복사해서 그냥 옴기면 되지 않나(?) 싶은데 그런게 아닌가 봐요..
뭘 신경써서 알아봐야하는지조차 모르겠네요...ㅜ
잘은 모르겠지만
이런게 도움 될거 같습니다.
1. 당근이의 AVR 갖구 놀기
http://cafe.naver.com/carroty/
2. 크로스 컴파일러의 사용
3. Qt IDE 사용??
http://qt.digia.com/
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
감사합니다
아 정말 감사합니다.
네이버 카페 가입했어요:) 크로스 컴파일러라는 새로운 것도 알게됬구요. 감사합니다!
GCC와 호환성이 어떻게 되는지 Greenhills
GCC와 호환성이 어떻게 되는지 Greenhills 본사에 문의(또는 기술지원)를 해보는 것도 좋을 것 같습니다(사용 버전에 따라 구체적으로).
Greenhills 소프트웨어의 컴파일러 소개 자료를 찾아보았는데요.
http://www.ghs.com/products/optimizingC++EC++Compilers.html
Compatibility 항목에 GNU C/C++ Extensions을 지원한다고 나오네요.
어느 Extensions들을 지원하는지는 자세히 알아보셔야 할 것 같습니다.
어쩔수 없이 GCC를 써야 한다면 무엇보다 소스코드가 (컴파일러에 의존적이지 않은) 표준 C/C++로 작성되도록 보장(계약) 해야 하지 않을 까요?
그리고 Greenhills 컴파일러로 포팅할 수 있도록 기술 지원을 약속한다던지요.
——
———
Life is a tragedy when seen in close-up, but a comedy in long-shot. - Chaplin, Charlie -
감사합니다
조언 정말 감사합니다. 덕분에 방향을 잡고 알아보고 있습니다.ㅜ
그린힐즈에도 알아보고, 말씀하신데로 "컴파일러에 의존적이지 않은 표준 C"로 작성하도록 협의해야겠습니다.
사무실에선 다들 잘 모르겠다고 안될거라고만 하는데, 정말 저에게 주신 금쪽같은 조언입니다. 감사합니다.
참고로 GCC에서 컴파일 옵션으로 표준(ansi,
참고로 GCC에서 컴파일 옵션으로 표준(ansi, c89, c90, c99 등)을 강제할 수 있습니다.
이 옵션을 따로 지정하지 않으면 디폴트로 GNU Extensions을 포함해서 컴파일 됩니다(C 코드에 대해선 gnu89가 디폴트 입니다).
옵션으로 표준을 지정하면 표준에 맞지 않는 코드는 컴파일 에러가 납니다.
표준으로 ansi, c89, c90 또는 c99을 사용하면 GNU Extensions을 못 쓰도록 강제 할 수 있습니다.
사용할 표준은 -ansi또는 -std= 옵션으로 지정할 수 있구요.
자세한 건 아래 링크를 참고 하세요.
[1] An Introduction to GCC - for the GNU compilers gcc and g++
http://www.network-theory.co.uk/docs/gccintro/gccintro_27.html
[2] Options Controlling C Dialect
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
[3] Language Standards Supported by GCC
http://gcc.gnu.org/onlinedocs/gcc/Standards.html
[4] Stackoverflow 질문/답변
http://stackoverflow.com/questions/8946797/gcc-options-for-strictest-c-code
http://stackoverflow.com/questions/1821952/gcc-options-to-enforce-ansi-c-standard-check
——
———
Life is a tragedy when seen in close-up, but a comedy in long-shot. - Chaplin, Charlie -
다른 사람을 위해
음.. 앞으로 이 글을 보게 될 다른 사람들 위해 댓글 남겨봅니다.
위에 달린 댓글 분 말씀처럼.. C언어 규격을 강제하게 되면 컴파일 에러는 나오지 않을 것으로 생각됩니다.
컴파일러에서 단순하게 문법 에러만 놓고 보면 그렇다는 것이지 호환성을 보장하지는 않습니다.
가장 큰 문제는 최적화 때문에 발생됩니다. GCC에서 빌드된 결과와 GHS에서 빌드된 결과가 확인하게 다르기 대문에 통합과정에서 큰 문제가 발생할 수 있습니다.
(GCC에서 빌드한 ELF를 타겟에 넣었을 때는 문제가 없으나, 그 코드를 그대로 GHS에서 빌드하여 타겟에 넣은 경우입니다)
컴파일러는 단순하게 어셈블리로 변환해주는데, 이 때에 큰 차이가 발생합니다.
실제 C 문법 에러가 아닌 어셈블리 출력결과에서 달라지기 때문에..된다 안된다의 문제가 아니라 나중에 신뢰성 확보에 큰 문제가 되어 더 오랜 시간을 소비할 수 있습니다.
코드 마이그레인션
GCC 컴파일러를 사용하여 작성된 프로젝트를 다른 컴파일 사용환경으로 이식하는 문제로 여겨집니다.
이럴 경우, 컴파일러 의존성이 있는 코드들을 이식(마이그레이션)하는 대상의 컴파일러와 호환되는 문법으로 수정해줘야 하는 작업이 수반될 수 있습니다.
이러한 수정 작업을 최소화 하기 위해서 초기 프로젝트 진행을 할 때, 표준을 기준으로 삼고 작업을 하는 것이 향후 유지 보수성이 좋겠습니다.
최근 다양한 컴파일러가 시장에 존재하고 있습니다만, 입베디드 및 코드 최적화 부분에 있어서는
IAR Systems IAR compiler 가 효능과 효율성에서 각광받고 있는 것으로 보입니다.
코드 마이그레이션은 다양한 변수들이 작용되므로, 신중하고 전략적으로 접근하시기를 권고 드립니다.
참고 링크 : IAR Systems 코드 마이그레이션
https://www.iar.com/kr/knowledge/support/technical-notes/compiler/migrating-some-gcc-inline-assembler-constructions-to-ewarm/
댓글 달기