2005년 6월 8일 수요일

[Tech]Open source compile

회사에 들어와서 처음 1년간 가장 고생했던 것이
Open Source Program들을 가져다가 compile하는 일이었다.


Windows User는 항상 install shield 같은 프로그램이 binary package를
잘 깔아주는 데.


Linux는 redhat의 경우 rpm을 제공하기도 하지만 버젼이 조금만 달라도 안되서 거의 의미가 없었다.
회사 오기 전까지는 rpm 찾아다가 시도해보고 안 깔리면 다 포기했었다.


하지만 대부분의 Open source 프로그램은 automake, autoconf, make로 packaging되어 있다.


automake, autoconf, make 매뉴얼도 대충 한 번씩 보긴 했는 데.
뭔지 잘 모르겠고 사람들이 쓰는 install script들도 많이 보고
Unix에서 주로 쓰는 convention을 배우고 나니 어느 정도 익숙해졌다.


설명은 README 혹은 README.[architecture], README.[OS]
설치법은 INSTALL, INSTALL.*


대부분
./configure --prefix=/내홈/local/프로그래명
make
make install
쯤 하면 잘 깔린다.


--prefix를 안주면 대게 /bin, /usr, /usr/local, /usr/bin, /etc 등에 설치된다.


Library는 대부분 '프로그램명-config'라는 파일을 실행하면
옵션들이 나온다.


APUE도 보고 compiler, linker, loader의 에러 메시지도 익숙해지고.
Unix Environment variable, shell script, perl script도 공부하고
Open source site들의 메뉴에도 익숙해졌다.


프로그램명_INCLUDE, 프로그램명_LIB, 프로그램명_BIN 등의 환경 변수를 보거나 PERL5LIB, LIBDIR, LIB_DIR, LD_LIBRARY_PATH 등을 보면 된다.
ldconfig도 잘 수행하면 된다.


대부분 screen shot, tutorial, download, document or manual 라는 메뉴를 가지고 있다.


그리고 대부분 서버 데몬은 환경설정 파일을 가지고 있는 데,
대게 몇 군데로 정해져 있다.
/etc, /설치된곳, ~내홈/.프로그램명rc, /설치된곳.conf, /var/프로그램명.conf, 데몬의 옵션(-c)으로 입력


잘 안될태는 log도 반드시 찾아봐야 한다.
automake, autoconf의 에러라든지, /var/log, */log/


설치가 성공했을 때는 항상 Architecture, CPU, OS, Kernel 버젼, 배포판 버젼, 각종 library 버젼, 설치 방식(binary, source compile), 설치 과정들을 잘 적어두면 매우 편리하다.


그리고 문제가 꼬였을 때는 추측으로 이것저것 맘대로 바꾸면 안된다.
그럼 분명 나중에 또 문제가 생겨서 설치의 문제인지 application의 문제인지 구분하지 못해서 디버깅이 매우 힘들다.
컴파일이 성공했을 때는 간단한 프로그램이나 검증된 프로그램을 반드시 실행해 본다.
(특히 *.so 파일 link는 항상 런타임에 문제가 된다.)


기능이 많다고 신기하다고 development 버젼을 받는 것은 위험하다.
그것은 그 프로젝트의 개발자들을 위한 것이다.
(경력이 10년 쯤 됐거나, 자신이 직접 만들거나 설계했거나 QA일때)
나같은 하수나 프로젝트 외부인은 그냥 stable 버젼을 쓰는 것이 좋다.
(소스코드를 이해하고 있지 않다면)

댓글 없음:

댓글 쓰기