Header 파일의 Feature 부분 변경 시 에러가 발생하네요.
[컴파일 에러가 나는데 버전 문제 같습니다.] 글을 올린 질문자 입니다.
우선, 이전에 답변해주신 라스코니님, qiiiiiiiip 님 정말로 감사합니다.
현재 크로스 컴파일을 진행 중입니다.
일반 리눅스 환경에서의 빌드는 모두 성공된 것을 확인했고, 타겟의 라이브러리를 통해서 컴파일을 하던 도중에 지속적으로 에러가 발생하더군요.
1. 타겟의 라이브러리 경로와 호스트의 라이브러리 경로가 다른 경우
2. 타겟의 라이브러리의 여러 Flag 들로 인해서 함수 자체가 컴파일 단계에서 불러오지 못하는 경우
3. 기타 이상한 것들
등등 이었습니다.
이번에 크로스 컴파일로 포팅하는 작업을 처음 맡게되었는데, 현재 제가 나아가고 있는 방향이 옳은 것인지 조차 구분을 할 수 없어서, 다시 한 번 선배님들께 여쭤보고자 합니다.
제가 진행한 방향은 아래와 같아요.
1. 기존의 호스트에서 포팅할 프로그램을 tar를 통해서 압축.
2. 타겟에서 해당 프로그램을 압축 풀기.
3. 해당 프로그램의 Makefile 작성.(안드로이드 기반이었기에..)
4. gcc 앞에 툴체인 변수 추가
5. 추가한 프로그램을 제외한 전체 빌드 진행(확인용 + 부분빌드용)
--- 여기까지가 준비단계였습니다.
6. 전체 빌드하는 build shell 에 부분 빌드할 프로그램 등록
7. 부분 빌드 진행
8. 대표적인 예로 wchar.h 이 존재하지 않는다는 에러 발생.
9. 가서 확인 시, wchar.h 내용이 없음.
이러한 이슈가 계속해서 발생을 합니다.
그래서 제가 위 문제를 해결하기 위해서 진행한 방법은..
GCC-4.3.3 내에 툴체인이 타겟의 라이브러리 뿐만 아니라 툴체인 자체를 컴파일 하기 위해서 가지고 있는 라이브러리도 있고,
그 외의 라이브러리도 존재했는데, 빌드로그를 봐도 어디에 쓰이는 지를 알 수 없더군요.. 하지만 해당 경로에 제가 필요로 하는 헤더들이 존재했습니다.
서로 다른 경로에 존재하는데 예를 들어서,
gcc-4.3.3으로 시작하는 툴체인 경로/usr/include : 타겟 라이브러리 경로
gcc-4.3.3으로 시작하는 툴체인 경로/linux-uclibc/c++/4.3.3 : 리눅스 라이브러리 경로
gcc-4.3.3/toolchain/~~~~~
등등으로 한 4, 5개정도 더 라이브러리가 존재합니다. 그래서 이러한 것들을 가져다가 lib이라는 경로에 저희 회사 이름을 딴 디렉터리를 하나 만들고, -I로 include해서 문제를 해결했습니다.
그리고 현재는 위에서 라스코니님, qiiiiiiiip 님께서 알려주신 방법대로 wcstombs(Wide character 형 문자열을 multi byte 형 문자열로 변환하는 함수)를 가지고 있는 stdlib.h 에 __UCLIBC_HAS_WCHAR__ 이라는 플래그가 걸려있어서
발생했던 에러이기에, 해당 플래그를 참조하는 Config 파일을 찾을 수 있는대로 찾아서 #undef -> #define 해주었습니다.
그리고 부분 빌드를 진행했음에도 해당 플래그가 설정되지 않은 것인지, 같은 에러가 발생했습니다.
그래서 해당 플래그를 아예 주석으로 막아버리고 한 번 부분빌드를 진행했더니, 정상적으로 부분빌드가 완료되었는데, 이전에 성공한 빌드에서 다음과 같은 에러가 발생합니다.
error: expected ')' before '*' token
error: expected declaration specifiers or '...' before 'wchar_t'
error: expected ')' before '*' token
error: expected ';', ',' or ')' before '*' token
신기한 것은 주석 처리로 플래그를 제거한 헤더(stdlib.h)를 사용해서 컴파일이 완료된 프로그램이 있는 반면,
기존에 존재하는 프로그램은 해당 헤더로 인해서 위와 같은 에러를 발생한다는 점입니다..
결론은.. 제가 진행하고 있는 방식이 옳지 않은 것 같다는 생각이 듭니다..
좀 문장이 길었습니다. 제가 진행한 방식을 여과없이 쭉 적었는데요..
위의 과정에서 어떤 부분은 정확히 진행한 것이고,
어떤 부분이 절대 해서는 안되는 행동이고.. 등을 알 수 있는 방법이 없어서, 글을 올리게 되었습니다.
Makefile 만 잘 작성하면, Cross Compile 은 자동적으로 따라올 줄 알았는데, 라이브러리 자체가 달라서 문제가 생기니.. 이러한 것들은 선배분들께서 어떻게 핸들하셨는지 정말 궁금합니다.
읽어주셔서 감사합니다....
타켓에 직접 옮겨서 빌드하시는 것 같네요. 체크해
타켓에 직접 옮겨서 빌드하시는 것 같네요.
체크해 보셔야 할 것이
1) 현재 타켓에 빌드하려고 하는 소스 버전이 해당 타켓에서 성공한 적인 있는 것인지...
2) 1)-만약 그렇다면 타켓에 빌드 환경 구성이 정확하게 되었는지... 즉 타켓에서 hello world 나 기타 다른 라이브러리가 잘 컴파일되고 설치되는지
3) 1)-만약 그렇지 않다면 빌드하려는 소스가 해당 타켓 및 빌드 환경에 포팅이 되어야 하는 상황인 것인지...
제 생각에 아마 3)의 상황인 것으로 보이네요.
일단 ad-hoc 으로 에러가 발생한 부분 위에서 다시 #undef를 추가해서 컴파일해 보세요.
너무 감사합니다.
현재 Ubuntu 환경에서 빌드하고 있습니다. 보드와 같은 환경이고, 최종적으로 이미지를 만들어서 보드 위에 올리는 것이 목적입니다.
제가 현재 빌드하려고 하는 프로그램은 Cryptopp 라는 프로그램으로 암호화 프로그램입니다. Static Library 로 만들어서 제가 실제 포팅하고자 하는 프로그램과 같이 컴파일 해야만 합니다.
홈페이지에서 확인한 결과 " fixed run-time validation error on x86-64 with GCC 4.3.2 -O2 "라는 부분을 확인할 수 있었고, 현재 제 GCC의 버전이 4.3.3 이므로 버전은 문제가 되지 않을 것 같습니다.
이 부분은 포팅이 되어야 합니다..
다시 한 번 undef 부분을 define 해서 진행해보겠습니다.
친절한 답변 감사합니다.
음 ..
애초에 toolchain 이 wchar 를 지원하도록 빌드되어 있지 않다면, gcc 버전에 상관 없이 toolchain 을 새로 빌드해야 할 것 같은데요.
toolchain builder 로 뭘 쓰시는지는 모르겠지만, toolchain 만 제대로 만들어져 있다면 원래 문제는 일어나지 않을지도..
아니면 '해당 프로그램' 에서 wchar 지원이 필요없다면 그걸 disable 시킬 수 있는 쪽으로 찾아 보는 것도 괜찮을 것 같네요.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
너무 감사합니다.
wchar 지원이 필요한 것 같아서 마지막 방법은 아마 힘들 것 같습니다. 함수 내에 wchar_t 변수를 사용하는 것이 몇몇 보입니다.
ToolChain builder는 uClibc 를 사용하고 있습니다. ToolChain은 한 번도 만들어 보지 못했습니다. 이 부분을 먼저 공부하고 진행하는 것이 좋을까요?
자세한 답변 정말 감사합니다.
음 ..
toolchain builder 가 compiler 로 gcc, libc 로는 uClibc 를 사용해서 toolchain 을 빌드하는 겁니다.
buildroot 나 crosstool-ng 같은 애들이 toolchain builder 에 해당하구요.
builder 에 따라 다르지만, wchar 나 locale support 같은걸 별도 옵션으로 빼놓은 애들도 있습니다.
이게 그와 관련있는지는.. 뭐 확인해 보면 알겠지만, 일단 체크 해 볼 필요는 있을것 같네요.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
네. 잘못 알려드린 것 같습니다. 방금 알아보니
네. 잘못 알려드린 것 같습니다. 방금 알아보니 ToolChain은 Mips를 사용하고 있고, lib는 uClibc, 컴파일러는 GCC 4.3.3 을 사용하고 있습니다.
말씀대로 위 ToolChain 으로 Toolchain의 설정을 확인하고 변경하는 방법과 Toolchain을 빌드하는 방법부터 알아보겠습니다.
감사합니다.
----
툴체인 종류 중 제가 사용하는 툴체인은 다음에 속하는 것 같습니다.
GNU/Linux toolchain (has -linux-gnu or -linux-gnueabi in its name):
it depends on Linux system calls and has C Standard Library, so it's intended for building user-space applications running under Linux. You should use it for building BusyBox, as it's user-space program.
음 ..
Crosstool-ng 가 toolchain builder 고 buildroot 는 builder 를 포함한..
Root filesystem builder 인데 섞어서 썼네요..
어쨌든 toolchain builder 가 자동으로 cross compiler 와 libc 라이브러리를 만들어 내는데..
이 컴파일러를 만들 때 wchar support 를 끌 수 있었다면..
헤더나 libc 라이브러리에 wchar 지원 함수가 없을 수도 있지 않겠는가? 하는 거죠..
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
정말 어렵네요..
말씀대로 현재 툴체인 디렉터리에 접근했고,
해당 디렉터리에서 해당 헤더파일을 한 번 찾아볼 생각입니다..
--------------------------------------------
ToolChain 경로 아래에
uClibc, gcc, gdb, linux 폴더에서 찾고는 있는데..
문제는 ToolChain_build_mips 라는 디렉토리가 하나 더 있네요..
그런데 이 ToolChain 을 빌드할 수 있는 Makefile 은 있는데, 별 내용도 없고.. Configuration 을 어떻게 할 수 있는지 자료도 찾기 쉽지 않고..ㅠㅠ
막막하네요..
____________________________________________
현재 제 build root 디렉터리 명이 gcc-4.3.3 인 것 같습니다. 안에 .config 파일이 있어서요.
https://wiki.openwrt.org/doc/howto/build -> 이거 보면서 찾고 있는데..
Flag는 정상적으로 =y 설정이 되어있고.. wchar.h 이나 등등에 대한 것은 찾을 수가 없네요..
--------------------------------------------
uClibc 밑에 wcs 관련한 경로가 libc 밑에 따로 존재하네요.. 그런데 c 파일이기는 한데.. 이걸 사용하면 될까요???
make menuconfig 로 들어가서 설정하는게 올바른 방법인가요?
--------------------------------------------
컴파일 시 접근하는 라이브러리 위치
해당 라이브러리 플래그 설정 위치
이 두 개의 경로를 지정한 파일의 위치를 알 수 있는 방법이 없을까요?
--------------------------------------------
https://www.cryptopp.com/wiki/GNUmakefile
위 경로에서 새로운 원본 다시 받아서 안의 GNUMakefile 을 Make로 변환하고, 툴체인으로 컴파일하니까 똑같은 에러가 나네요..
음 ..
openwrt 라면 buildroot 랑 menuconfig 이 비슷했던 걸로 기억하는데..
toolchain 이나 C Library 와 관련된 메뉴가 있나 한 번 찾아 보셔야겠네요. (menuconfig 에서 WCHAR 로 검색해 보시거나)
어쨌든 C Library 로 uClibc 를 선택하면 RPC 나 WCHAR support 를 세부적으로 설정할 수 있는 메뉴가 있을 겁니다.
WCHAR Support 를 끄면 다음과 같이 stdlib.h 은 물론 다른 헤더에서도 wchar 지원 함수들이 사라집니다.
$ diff -u x86_64-buildroot-linux-uclibc-wchar/sysroot/usr/include/stdlib.h x86_64-buildroot-linux-uclibc-no-wchar/sysroot/usr/include/stdlib.h --- x86_64-buildroot-linux-uclibc-wchar/sysroot/usr/include/stdlib.h 2016-08-08 08:43:31.941328675 +0900 +++ x86_64-buildroot-linux-uclibc-no-wchar/sysroot/usr/include/stdlib.h 2016-08-08 08:33:10.209353263 +0900 @@ -26,7 +26,6 @@ /* Get size_t, wchar_t and NULL from <stddef.h>. */ #define __need_size_t #ifndef __need_malloc_and_calloc -# define __need_wchar_t # define __need_NULL #endif #include <stddef.h> @@ -139,8 +138,7 @@ #define MB_CUR_MAX (__ctype_get_mb_cur_max ()) extern size_t __ctype_get_mb_cur_max (void) __THROW __wur; #else -# define MB_CUR_MAX (_stdlib_mb_cur_max ()) -extern size_t _stdlib_mb_cur_max (void) __THROW __wur; +# define MB_CUR_MAX 1 #endif @@ -823,29 +821,6 @@ #endif /* use MISC || use X/Open Unix */ -__BEGIN_NAMESPACE_STD -/* Return the length of the multibyte character - in S, which is no longer than N. */ -extern int mblen (const char *__s, size_t __n) __THROW __wur; -/* Return the length of the given multibyte character, - putting its `wchar_t' representation in *PWC. */ -extern int mbtowc (wchar_t *__restrict __pwc, - const char *__restrict __s, size_t __n) __THROW __wur; -/* Put the multibyte character represented - by WCHAR in S, returning its length. */ -extern int wctomb (char *__s, wchar_t __wchar) __THROW __wur; - - -/* Convert a multibyte string to a wide char string. */ -extern size_t mbstowcs (wchar_t *__restrict __pwcs, - const char *__restrict __s, size_t __n) __THROW; -/* Convert a wide char string to multibyte string. */ -extern size_t wcstombs (char *__restrict __s, - const wchar_t *__restrict __pwcs, size_t __n) - __THROW; -__END_NAMESPACE_STD - - #ifdef __USE_SVID /* Determine whether the string value of RESPONSE matches the affirmation or negative response expression as specified by the LC_MESSAGES category되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
이른 아침부터 감사합니다.
네. stdlib.h 에 __UCLIBC_HAS_WCHAR__ 이라는 feature가 있고, 해당 feature가 현재 #undef 되어있습니다.
uClibc_config.h 라는 곳에서 해당 Feature가 막혀있는 것을 확인했고,
해당 Feature 를 참조하는 ext-tool.mk 라는 곳에서 아래의 로직을 통해서 확인하는 것을 확인했습니다.
check_uclibc_feature = \
IS_IN_LIBC=`grep -q "\#define $(1) 1" $(3) && echo y` ; \
if [ x$($(2)) != x"y" -a x$${IS_IN_LIBC} == x"y" ] ; then \
echo "$(4) available in C library, please enable $(2)" ; \
exit 1 ; \
fi ; \
if [ x$($(2)) == x"y" -a x$${IS_IN_LIBC} != x"y" ] ; then \
echo "$(4) not available in C library, please disable $(2)" ; \
exit 1 ; \
fi
check_uclibc = \
SYSROOT_DIR="$(strip $1)"; \
if ! test -f $${SYSROOT_DIR}/lib/ld-uClibc.so.* ; then \
echo "Incorrect selection of the C library"; \
exit -1; \
fi; \
UCLIBC_CONFIG_FILE=$${SYSROOT_DIR}/usr/include/bits/uClibc_config.h ; \
$(call check_uclibc_feature,__UCLIBC_HAS_WCHAR__,BR2_USE_WCHAR,$${UCLIBC_CONFIG_FILE},Wide char support) ;
문제는 위의 uClibc_config.h 이 있는 위치는 CVS 디렉터리가 존재하지 않으며, 이 말인 즉슨 다른 곳에서 받아서 이곳에 넣어주는 것
같습니다.
결국 uClibc_config.h 도 어딘가에서 설정이 되어서 복사된 것일텐데 이 부분을 찾을 수가 없네요.
저 uClibc_config.h 의 #undef 부분을 #define 하더라도 전체빌드 시, 다시 원상태로 복구됩니다..
음 ..
혹시나 해서 지난 댓글 봤더니, 이미 다른 분들이 답을 주신것 같은데, 딴 곳에서만 찾으시네요.
toolchain 이나 각종 package 빌드 에 대한 정보는 openwrt 의 toolchains 와 package 디렉토리에 있습니다.
나중에라도 빌드 옵션을 조정하거나, 패치를 적용하거나 할 일이 있다면 거기에서만 작업하시면 될겁니다.
openwrt/toolchain/uClibc 에 가면 Config.in 이랑 Makefile 등이 다 있을겁니다.
config-0.9.3x.y/ 디렉토리에는 몇 가지 config 파일들이 있는데, WCHAR 설정은 common 에 있네요.
backfire 소스는 svn 에서 받으라던데, 연결은 안 되네요.
Config.in 에 Wide Character 설정 메뉴가 없는 걸 보니.. 그냥 default 로 고정되어 있나 봅니다.
대충 Makefile 열어 보니 kconfig.pl 로 .config 파일 만들어서 이걸로 uClibc 빌드할 때 쓰나 보네요.
일단 소스만 놓고 봤을 때는 10.03 이후 버전은 Wide Char 가 default 로 적용되어 있네요.
main trunk 에서는 uClibc 가 musl 로 대체되어 있던데, 어쨌거나 uClibc 의 기본값은 y 입니다.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
현재 제 환경의 OS는 우선 OpenWRT는 아닌 것
현재 제 환경의 OS는 우선 OpenWRT는 아닌 것 같습니다. 이 부분은 어떻게 알 수 있는지 잘 모르겠습니다.
말씀해주신대로 찾아보니 build/gcc-4.3.3 아래에 Toolchain 과 Package 가 있는 것을 찾았고, 앞으로의 작업은 이곳에서 진행하겠습니다.
이전에 Staging_dir 에서 작업한 결과가 날아가는 이유를 몰랐었는데, clean 하고 보니 싹 날아가는 디렉터리더군요.
그래서 어디선가 Copy할 것이라고 생각했는데.. 그게 ToolChain 인가 봅니다.
네 uClibc 의 기본값은 y로 되어있는 것을 확인했습니다.
/toolchain 디렉터리에서 그 어디에서도 헤더파일을 찾을 수가 없습니다. 혹시 라이브러리는 다른 곳에 위치하는 건가요? 어디서 Copy 해오는 것인지 잘 모르겠습니다.
UCLBIC_HAS_WCHAR = y 라고 설정되어있는 것을 확인했는데, 이것 외에도 따로 설정할 수 있는 방법이 있는 건가요??
음 ..
이전에 openwrt 를 언급하시기에 그걸 사용중인가 보다.. 하고 생각했었는데..;;;
자신이 뭘 다루고 있는지 정확히 설명하시지 못하신다면, 계속 뜬구름 잡으면서 시간 낭비만 하고 있을 공산이 큽니다.
모든 정보는 질문하신 분만이 갖고 있습니다.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
죄송합니다. Qualcomm Atheros 에서
죄송합니다. Qualcomm Atheros 에서 구매한 것인데, OpenWRT 와 같이 따로 플랫폼이 올라와있지는 않고, 그대로 리눅스를 OS로 사용하고 있는 것 같습니다.
해결 방법은 wcstombs 라는 함수 부분이 정말 사용되는 것이 맞는지를 확인하고, 사용되지 않을 경우, 참조 부분에 Flag를 걸어서 주석처리 하거나
아니면 근본적으로 해결하는 방법인 Config 파일을 찾아서 해당 Flag를 해제하는 방법인데,
WCHAR 을 Configure 해주는 부분을 정말 찾기가 힘든 것 같습니다.
우선 해당 부분을 막아서 빌드를 완료하고, 사용되지 않을 경우면 괜찮지만, 사용되는 경우에는 Flag 여는 방법을 찾아봐야겠습니다.
제가 아직 6개월차라.. 이런 것을 처음 접해서 잘 모르겠네요.. 정말 매번 감사합니다.(__)
음 ..
LSDK?? 만약 그렇다면 buildroot 2009 년도 버전을 썼던 걸로 기억하는데..
흠.. 아마도 각각의 타겟 보드 별로 config 파일이 어딘가에 저장되어 있을겁니다.
그 설정 파일을 buildroot 쪽에 .config 으로 복사한 후에 빌드하지 않을까 싶은데..
타겟 보드의 설정 파일에 BR2_USE_WCHAR 라는 키워드가 있는지 확인해 보면 될 겁니다.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
LSDK.. 제가 cvs 브랜치로 받기 이전에 중간에
LSDK.. 제가 cvs 브랜치로 받기 이전에 중간에 들어가는 경로에 있었던 기억이 납니다.
# Copyright (C) 2006-2009 by the Buildroot developers 라는 부분은 있습니다.
정확히 buildroot의 위치가 어디인지 알기가 쉽지 않네요.
gcc-4.3.3 바로 아래에 있는 .config 파일에서 BR2_USE_WCHAR 라는 키워드를 찾았습니다.
gcc-4.3.3/package/config 로 지정된 경로도 있는데 어떤 역할의 경로인지 잘 모르겠네요.
우선 해당 Feature가 is not set으로 주석으로 막혀있습니다. 해당 부분을 =y로 변경하고 진행해보겠습니다.
----------------------------------------
아! BR2가 Buildroot2를 의미하는 거였군요!
BR2 GCC Version, UCLIBC version 등에 대해서 설정하는 auto.conf 파일도 찾았습니다. 지금 문제와 큰 의미는 없는 것 같지만..
여기서 하나 얻은 것은 다음 부분인 것 같습니다.
BR2_UCLIBC_CONFIG="toolchain/uClibc/uClibc-0.9.30.config" 라고 경로가 나와있네요.
---------------------------------------
위 부분에서 진행한 .config 파일도 마찬가지로 원래대로 복구되네요. 아마 이것도 어디선가 카피해오는 것 같습니다.
.config 파일에 설정하는 부분이 혹시 Config.in 에 입력해주어야 하나요? .config에 설정되어있는 값이 훨씬 많기는 한데.. 몇몇 정확하게 맞아떨어지는 부분이 있네요.
---------------------------------------
수정해서 해당 부분은 넘어갔습니다. .config 파일로 복사하는 원본을 찾았습니다. 그래서 해당 부분의 Feature를 수정했는데, 원상태로 되지 않고, 제가 수정한 상태로 남아있으며, 적용된 듯 합니다. 감사합니다. 이렇게 진행하니까 다른 곳에서 에러가 발생해서 이런 방법으로 하나씩 feature를 수정해가려 합니다.
어제 처음 알았는데, 이런 툴체인은 칩 밴더에서 제공해주는 것이라 하더라구요. 그리고 라이브러리도 칩이 돌아가게끔만 최소한으로 설정되어있고.. 그래서 사용자는 이런 것을 조금씩 고쳐가면서 사용하는 것이라고 하던데,
이렇게 계속 하나씩 에러가 발생하는 구간을 고쳐나가는 게 포팅하는 올바른 방법일까요? 방향만 맞았으면 좋겠어요..
ymir님 정말 감사합니다. 덕분에 wcstombs 구간은 넘어간 것 같습니다.
음 ..
처음부터 LSDK 얘기가 나왔더라면 하는 아쉬움이 남긴 했지만.. 어쨌든 실마리를 찾은 듯 하니 다행입니다.
툴체인은 그냥 컴파일러, 라이브러리, 디버거 등의 집합이라 그냥 필요한 대로 타겟만 맞춰서 대충 만들어 써도 됩니다.
벤더 입장에서는 고객들이 검증된 환경에서 별도의 사전 작업이나 삽질 없이 바로 작업할 수 있도록..
자신들이 작업했던 내용을 묶어서 배포한 것 뿐이죠.
예전에 LSDK 썼을 때에는 c++ 에 다른 개발 환경이 필요해서, 아예 툴체인을 따로 만들어서 개발 환경을 세팅하고..
미리 빌드해 놓은 커널/드라이버만 가져다가 썼었습니다.
그리고 문제를 해결하는 방법이 한 가지만 있다면 모를까.. 정답이냐 아니냐는 문제가 아닌 것 같습니다.
그 상황에 맞는 적절한 방법 하나를 고를 수만 있으면 되죠.
보다 더 나은 방법은 없는지 끊임 없이 고민하고 하다 보면 어느새 올바른 방향으로 가고 있을 겁니다.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
정말 감사합니다. 아직 이번 문제를 완벽히
정말 감사합니다.
아직 이번 문제를 완벽히 해결하지는 못했지만, 지금까지 하면서 많이 배운 것 같아요.
툴체인을 만들어본 적이 없고, 만약 문제가 발생하면, 아직 책임질 수 있는 단계가 아니라 많이 부담됩니다..
꼭 시간내서 윈도우에서 만든 프로그램을 VM의 linux에 포팅하기 위해서 툴체인을 한 번 만들어보는 것을 시도해봐야겠습니다.. 단순히 회사에서 되도록만 위험부담 없이 되게만 하려고 하니 제대로 배워가는 것 같지 않아요..
이렇게 시간 할애해 주셔서 정말 감사합니다.
댓글 달기