컴파일 지옥

선임님이 진행 중인 프로젝트에 이미지 로더로 쓸 라이브러리가 컴파일이 잘 안 된다고 해서 대신 살펴봤다. 그래서 opencv를 컴파일하기 시작했다. 이게 나의 무덤이 될줄이야...

(환경 : sparc, solaris, gcc)

그냥 configure, make 하니 "ld: fatal: relocations remain against allocatable but non-writable sections"란 에러가 난다. 구글 해보니 Linker and Libraries Guide : Position-Independent Code란 문서가 나온다. 이해 못한 부분이 있지만, 대략 보니 shared library 만들 때 문제라길래 static library로 만들도록 설정을 수정했다. 자세히 읽어보는 것은 나중에 하고, 일단 빨리 컴파일해서 넘겨줘야지라는 생각이었다.

설정을 바꿔 컴파일하니 "grfmt_jpeg.cpp:108: parse error before `void'"란 에러가 난다. 뭔가 하고 소스의 해당 부분을 살펴보니 METHODDEF 가 눈에 띈다. 이게 어디 있는 건가 한참 찾았다. 결국 libjpeg의 jmorecfg.h에 선언되어 있는데 버전에 따라 형태가 달라서 문제가 발생했다. (옛날 버전 : #define METHODDEF static. 새 버전 : #define METHODDEF(type) static type) 그래서 libjpeg을 새로 컴파일했다.

이정도는 귀엽다.

다시 컴파일하니 "sstream: No such file or directory" 에러가 난다. 디렉토리를 뒤져보니 sstream이 없다. 대신 strstream이 있다. 아니 이건 또 뭐야. 구글신께 빌자 strstream은 sstream의 옛날 이름이라고 일러주신다. gcc 버전이 오래된 게 문제다. 시스템을 여기저기 뒤지고 다녀서 비교적 최신 gcc를 찾았다. 만세! (이쯤되면 슬슬 지친다. 시스템의 디렉토리 구성이 상당히 복잡해서 뭐 찾으려면 시간도 많이 걸리고 무척 번거롭다.)

이젠 됐겠지 생각했지만 어김없이 "`wmemset' undeclared"라며 에러를 내뱉는다. 또 한참을 웹과 디렉토리 지옥을 뒤지고 다녀서 c++config.h 파일의 "#define GLIBCXX_HAVE_WMEMSET 1"를 찾았다. gcc는 glibc에 wmemset이 있다고 생각하는데 실제로는 없어서 생기는 문제인 것 같다. 아직 정확한 건 모르겠고, 이상 얄닥꾸리한 꼼수를 써서 지나가게 만들었다. (glibc를 다시 컴파일하려고 했는데, solaris는 더이상 공식적인 지원을 하지 않는다.)

그 다음은 "`PySlice_GetIndicesEx' undeclared". 이젠 새삼스럽지도 않다. 뭐 위와 마찬가지의 방법들로 뒤져봤더니 python 버전이 문제. 2.2.3에서 2.4로 바꿨다.

#error "LONG_BIT definition appears wrong for platform (bad gcc config?).". pyport.h 파일에 정의되어 있는 건데, 어떤 32비트 시스템에서 LONG_BIT 값을 64로 잘못 세팅한 문제를 잡아내기 위한 부분이다. 하지만 우리 시스템은 전부 64비튼데? LONG_BIT 값과 비교하는 SIZEOF_LONG 값을 찾아보니 4로 되어 있다(pyconfig.h). python을 32비트 머신에서 컴파일한거다! OTL

여기까지 하고 퇴근했다. 다른 거 하려고 야근 신청한 건데 결국 컴파일하다 하루 다 갔다. 결론은 target machine을 바꾸든지(x86-linux에서는 python만 새로 컴파일하면 될 것 같다.), gcc와 python을 새로 컴파일하든지, 이미지 라이브러리를 다른 걸로 바꾸든지.