컴파일 에러가 나는데 버전 문제 같습니다.
안녕하세요.
현재 크로스 컴파일을 하는 업무를 맡았습니다.
인터넷에서 읽고 진행하는터라 정말 많이 힘드네요..
제가 아는 크로스 컴파일이라는 것이, 임베디드 CPU가 읽을 수 있는 바이너리를 만들도록 현재 PC에서 해당 환경의 GCC로 컴파일하는 것을 말하는 것으로 알고 있습니다.
그래서 ToolChain gcc 를 통해서 컴파일을 진행하고, 리눅스 디폴트 라이브러리(/usr/include) 를 사용하는 것이 아닌 ToolChain의 디폴트 라이브러리 위치를 참조하는 것으로 알고 있습니다.
제 환경은 아래와 같아요.
Ubuntu 버전: 12.04.5 LTS
GNU/Linux 버전 : 3.13.0-86
디폴트 GCC 버전 : 4.6
임베디드에 Cryptopp(암호화 복호화 오픈소스)를 포팅하려고 하는데, 계속 컴파일 에러가 발생합니다..
GCC 4.6 디폴트에서는 Makefile 작성해서 make하면 정상적으로 컴파일이 되는데,
임베디드 CPU 환경의 커널 버전은 2.6.31이고 GCC 버전이 4.3.3 이어서, 그에 맞는 Cryptopp를 다운(5.6.0 & 5.6.2)받아서 컴파일을 했습니다. 그런데 계속,
cryptopp/misc.h:554: error: 'wcstombs' was not declared in this scope
에러가 발생합니다.
이런건 cryptopp 버전 문제일까요 아니면 GCC 버전의 문제일까요?
제가 컴파일 과정에서 인클루드를 잘못해서 발생한 걸까요? 사실 따로 인클루드할 내용이 없고, 디폴트 라이브러리를 컴파일 하던 도중에 에러가 발생합니다..
----------------------
호스트 라이브러리와 타겟 라이브러리에서 wcstombs 라는 부분이 둘 모두 정의가 되어있는 것 같은데, 타겟의 경우에는 #ifdef __XXXX__ 로 조건이 걸려있습니다.
이럴 때, -D 옵션을 사용해서 -D__XXXX___ 라고 하면 될 것 같은데 해당 방법도 적용되지 않네요..
흠... -_-;;
해당 헤더 파일(cryptopp/misc.h)에서 stdlib.h를 include하고 있는지 확인해보세요.
답변해주셔서 정말로 감사합니다.
네. 해당 에러 발생하자마자 확인했었는데, 정확히 include 하고 있습니다.
현재 호스트 PC의 개발환경에서는 위와 같은 컴파일 오류가 발생하지 않습니다.
그런데 포팅해야 하는 환경의 툴체인으로 컴파일 시 해당 오류가 발생해서 골이 아프네요..
cryptopp 사이트에서 확인해보니, 현재 받은 버전이 지원하는 GCC 버전 범위가 3.2~5.2 까지인 것 같은데,
현재 개발환경의 GCC는 4.6.3이고, 포팅하는 환경의 GCC는 4.3.3이므로 이것도 문제가 아닌 것 같습니다.
호스트 피씨에서는 glibc이고 포팅환경에서는 uClibc 사용으로 인한 문제인 건지.... 도저히 감이 오지 않습니다..
혹시나 싶어서 -I 옵션으로 gcc-4.3.3 라이브러리를 include 했는데도, 에러가 발생하고 있습니다.
사용하고 계시는 크로스 컴파일 환경(GCC
사용하고 계시는 크로스 컴파일 환경(GCC 4.3.3)에서의 stdlib.h가 wcstombs 함수 정의를 가지고 있는지 확인해 보세요.
답변해주셔서 정말로 감사합니다.
네 방금 확인해봤습니다.
cstdlib 에서 stdlib.h 을 참조하고 있는데, 현 위치가 tr1/stdlib.h 로 잡혀있기에
#include >>> #include
로 변경했고,
stdlib.h 에서 확인해보니,
.... 없네요;; 내용이;;
Include 경로 변경하고 다시 시도해보겠습니다. 감사합니다.
이것과 관계가 있을 수도
이것과 관계가 있을 수도 있겠네요.
https://stat.ethz.ch/pipermail/r-devel/2010-February/056601.html
답변해주셔서 정말로 감사합니다.
이 글도 읽어봤는데, 제가 크로스 컴파일을 하면서 궁금한게.. 참조하는 헤더를 수정해도 되는가 입니다..
만약 된다면..
#ifdef XXX
else
#endif
시도해보려고 합니다.
misc.h 에 #include
misc.h 에
를 추가하는 것으로 오류가 해결되긴 하나요?
아뇨. 디폴트 경로 잡힌거 무시하고, -I로 해당
아뇨. 디폴트 경로 잡힌거 무시하고, -I로 해당 헤더파일을 참조하는 경로 설정하고, 추가했음에도 wcstombs 를 찾을 수 없다는 에러가 나옵니다.
안에 들어가서 확인해보니, 특정 flag를 주는게 있어서 해당 부분 flag도 define 했는데도 안되네요..
-------------------------
-I로 다른 디렉터리 경로를 참조했더니 해당 에러는 출력되지 않고,
error: '::div_t' has not been declared
error: '::ldiv_t' has not been declared
...
에러가 출력되고 있습니다.
------------------------
원 상태로 돌렸습니다..
디폴트 경로를 바꾸거나, 특정 flag를 강제로
디폴트 경로를 바꾸거나, 특정 flag를 강제로 define 하는 것은
별로 좋은 방법이 아닌 것 같습니다..
복잡한 문제가 아닐것 같은데... 안타깝네요..ㅎㅎ
네.. 사실 저도 이렇게 하는 것은 좋지 않을 것
네.. 사실 저도 이렇게 하는 것은 좋지 않을 것 같아서.. 위에 라스코니 님께서 답변해주셔서 문제점이 발견된 것 같습니다. 한 번 시도해봐야할 것 같습니다..ㅠㅠ 다른 cpp는 되는데, 왜 특정 프로그램의 cpp는 라이브러리를 참조하지 못하는 것인지 알 수가 없네요..
특정 cpp가 라이브러리를 참조하지 못하는 문제가
특정 cpp가 라이브러리를 참조하지 못하는 문제가 아니라,
컴파일 타임에서 특정함수 wcstombcs의 선언을 찾지 못하는 문제(헤더를 include했음에도)
라고 말하는게 정확하겠네요.
두가지 가능성이 있겠네요.
1. 사용하시는 툴체인에 wcstombcs 가 구현되지 않았거나. (라스코니님의 답변)
2. 구현은 되어있으나 컴파일러버전 문제(또는 namespace문제) 로 제대로 찾지 못하거나..
디폴트경로를 바꾸지 않은 바닐라상태에서 실제로 include되는 stdlib.h 헤더파일에
wcstombcs의 선언이 없다면 1번일 가능성이 높겠습니다.
아무리 경로를 바꾸서 컴파일 에러를 없애도 결국 링크할때 에러가 날테니
툴체인을 다시 configure해서 빌드해야 하겠지요.
제가 드린 답글은 2번 경우에 대한 것이었습니다.
아.. 말씀하신 위 2 가지 경우로
아.. 말씀하신 위 2 가지 경우로 찾아보겠습니다.
만약 1번이면 정말 힘들어지겠네요...
정말 감사합니다.
크로스 컴파일 툴 체인의 라이브러리가 wcstombs
크로스 컴파일 툴 체인의 라이브러리가 wcstombs 함수를 가지고 있는지 확인해 보세요.
elf 포맷이면 아마 아래의 명령으로 확인이 가능할 겁니다.
예) "objdump --syms *.lib | grep wcstombs" 등등
출력되는 리스트 중에서 _wcstombs 같은게 있으면 툴 체인 라이브러리에 들어있는 거거든요.
제 생각에 gcc 4.3.3 이면 그리 낡은 컴파일러도 아니니 아마 있을 겁니다. 단지 크로스 컴파일 환경이나 make 가 잘못 설정되어 있는 것으로 보이네요.
와.. 정말 감사합니다.. 너무 신경써주셔서
와.. 정말 감사합니다.. 너무 신경써주셔서 감사해요..
-D 옵션을 사용해서 -D__XXXX___ 라고 하면
아니요.. 툴체인을 빌드 할 때 __XXXX__ 가 결정될겁니다.
uGlibc 를 말씀하셔서 잠깐 찾아보니
__XXXX__ 는 __UCLIBC_HAS_WCHAR__ 를 말씀하시는것으로 보이고,
prebuilt binary를 받아보니
include/bits/uClibc_config.h 파일에
#define __UCLIBC_HAS_WCHAR__ 1
로 정의되어 있네요.
그리고 uGlibc를 컴파일할때
[ ] Wide Character Support
를 선택할 수 있고 디폴트는 disable 인 것 같네요.
--
제한된 정보에서 말씀 드린 것이라 틀릴 수 있습니다. 상황에 맞게 받아들이세요.
어렵지 않은 일인데 필요 이상으로 고민하시는 거 같아 잠시 참견해봤습니다.
아.. 정말 감사합니다..(__) 위에
아.. 정말 감사합니다..(__) 위에 __UCLIBC_HAS_WCHAR__ 이 부분은 정확하세요. 중요하지 않은 것 같아서 XXXX라 표기했습니다. 네 config 파일 부분도 확인했었는데, 제가 툴체인에 대한 개념을 처음 접해서 정의가 되었어도 안되었나 확인차.. 그래서 그냥 마구잡이로 설정해보고 있었습니다.
"
그리고 uGlibc를 컴파일할때
[ ] Wide Character Support
를 선택할 수 있고 디폴트는 disable 인 것 같네요
"
부분까지 알아봐주셔서 정말 감사합니다. 저 default 가 disable이면 제가 enable로 변경해야 하겠군요. 정말로.. 감사합니다.. 참견이라뇨.. 당치 않습니다.
위와 같은 정보는 어디서 얻을 수 있는지 여쭤봐도 되나요? 이전에 아카이브 만들 때도 많은 에러가 발생했는데, 사실 이와 비슷한 것 같아서 근본적인 부분을 해결해보려고 합니다..
_______
이전에 포스트해주신 내용처럼 Version 문제일 수도 있다고 생각합니다.
커널의 경우에는 버전이 상관없을 것 같은데, 제가 현재 컴파일하려는 프로그램이 GCC 3.2~4.X 까지 지원한다고 확인을 했던 터라.. GCC 버전과 상관이 있나 싶기도 합니다..
uClibc 버전과 GCC 버전 과의 관계는 잘 모르겠습니다.
우선 GCC 4.3.3 매뉴얼보고 있었는데, uClibc 관련해서 찾은 후 설정 부분을 보겠습니다.
정말로 너무 감사합니다..
우선 Configuration 파일을 찾아서
우선 Configuration 파일을 찾아서 보니
config UCLIBC_HAS_WCHAR
bool "Wide Character Support"
default n
help
Answer Y to enable wide character support. This will make uClibc
much larger. It is also currently required for locale support.
Most people will answer N
라고 적혀 있네요. Y로 설정하기 위해서 저 boolean을 설정하는 부분을 찾아봐야할 것 같습니다.
정말 감사합니다.. grep으로 문서 다 찾아도 "Wide Character" 부분을 몰랐다면 실마리도 못 찾았을 것 같아요.
툴체인 디렉토리에서
툴체인 디렉토리에서
include/bits/uClibc_config.h
파일에서 __UCLIBC_HAS_WCHAR__ 가 어떻게 정의되었는지 확인해보면 되겠네요.
#define __UCLIBC_HAS_WCHAR__ 1 인데 오류가 나면 다른 문제이고,
#undef __UCLIBC_HAS_WCHAR__ 로 되어있으면 툴체인을 수정해야할테고요.
와.. 찾았습니다. 툴체인 설정 부분에
와.. 찾았습니다. 툴체인 설정 부분에
#define __UCLIBC_HAS_CTYPE_CHECKED__ 1
#undef __UCLIBC_HAS_CTYPE_ENFORCED__
#undef __UCLIBC_HAS_WCHAR__
#undef __UCLIBC_HAS_LOCALE__
로 undef 되어있었습니다.. 정말 감사합니다.
ㅠ.ㅠ 문제점을 찾았네요.. 어떻게 고마움을 표현할 길이 없네요.ㅠㅠ
댓글 달기