멍청한 M$놈들이 지들이 만든 DLL 의 참조 오류가 많아지자, manifest 개념을 도입해서 DLL 특정 위치 해결 점을 어찌저찌 해 보고자 해 놓고선, 컴파일러 자체가 Visual Studio 에서 개발에서 쓰는 DLL 이 없으면 표준 WindowsAPI 로 도는 프로그램이 돌지도 못하게 해 놓은 것이죠.
M$ 개발자들이 편하니, 사용자가 되는 VS 개발자가 개노가다 해야 하는 겁니다. 참으로 븅신같은 현상이 아닐수가 없죠.
분명히 프로젝트를 표준 Windows API 만을 사용하는 프로젝트로 만들어도, 저놈의 알수도 없는 DLL 참조 오류는 저를 절망의 늪으로 끌고 가기에, 그냥 컴파일러를 gcc 로 변경 하였습니다.
프로그램 자체를 리소스 다이얼로그 생성 방법을 사용했을 뿐 인데다, 내부 프로그래밍도 모두 WIN API 사용만을 하도록 하고, c++ 의 std 라이브러리만 사용 했으니, 약간의 컴파일러간의 차이점만 적용 하면 컴파일이 가능 했습니다.
이번에 안 것이지만, 표준 std::fstream 이 Visual Studio 와 gcc 가 다르더군요.
개발자가 쓰기는 Visual Studio 가 편하지만, 이게 C++ 표준이 아닌 M$ 가 지들 맘대로 바꾼 것인걸 아니 더욱 더 기가 찼습니다.
하나부터 열까지 다 자기들 맘대로인 M$ 에게 정말 경의를 표하는 바 입니다.
이런 경우 때문에 저는 개발자가 편하면 사용자에게 죄를 짓는 짓이다. 라고 하는 것 입니다.
그런이유로 .. MFC 개발자님들에겐 죄송하지만, 전 MFC 를 경멸합니다.
어쨋든.
CodeBlocks 의 import 로 Visual Studio Solution 파일을 import 후, DEBUG 나 UNICODE 등의 #define 을 컴파일러 옵션에 지정하였습니다.
내부에 다국어 지원 문제로 BOM 헤더가 있는 cpp 파일을 gcc 가 컴파일 하지 못하는 문제 때문에 gcc 프로젝트만 별도로 다국어 문자열 저장 코드를 BOM 헤더가 없는 UTF-8 형태로 다른 이름 저장 하여, 프로젝트에서 해당 파일을 교체 하여 컴파일 하도록 하였습니다.
나중에 VS 에서 수정하면 해당 파일도 함께 수정 해야 하는 것 이지만, notepad++ 에서 전체 복사, 붙이기로 한번씩만 해 주면 되니 이정도 고생은 좀 감수 해야 하겠지요.. (아싸리 망할놈의 M$ Visual Studio 를 아예 안쓰고 싶습니다만 ...)
다 됐다 싶어 빌드를 하니 .. 어라! 이건뭔가요?
왠 리소스 오류가 납니다.
혹시 unicode 인가 해서 보니 그냥 ANSI 입니다.
외국 포럼을 돌아 보니, 역시 해답이 있더군요.
Codeblocks 에서 RC 컴파일시, 옛날 명령어 사용으로 일부 RC 파일을 컴파일 하지 못하는 경우가 있었습니다.
그래서 저는 다음과 같이 컴파일 옵션을 직접 제가 주도록 변경 하였습니다.
$rescomp -i $file -J rc -o $resource_output -O coff -Isrc -Ires -Ilib
이걸 다음과 같이 directory 참조 구문으로 지정해 줘야 합니다.
$rescomp -i $file -J rc -o $resource_output -O coff -I.\src -I.\res -I.\lib
이는 실제 CodeBlocks 의 오류라기 보단, minGW 에 포함되는 windows RC compiler 인 windres.exe 의 오류라고 하는군요.
혹시라도 저처럼 리소스 컴파일에 이유를 못 찾고 포기하려는 분이 계시다면, 위와 같이 직접 컴파일 옵션을 변경해서 만들도록 해 보시길 바랍니다.
