기본 콘텐츠로 건너뛰기

추천 가젯

Tmux 환경에서 Vim 컴파일 시 발생하는 termio/termios 감지 오류 해결 방법

 리눅스 환경에서 소스코드를 직접 빌드하다 보면 의외의 환경 변수나 터미널 세션 설정 때문에 엉뚱한 빌드 에러를 마주할 때가 있습니다. 대표적인 예로 Tmux 세션 내부에서 Vim 소스를 컴파일할 때 발생하는 termio/termios 감지 오류 가 있습니다. 이번 글에서는 해당 에러가 발생하는 원인과, 단순한 clean 으로는 해결되지 않는 이유 및 올바른 해결 방법을 정리합니다. 1. 문제 원인 Vim의 소스 코드 빌드 과정( configure )은 시스템이 System V 계열인지 Linux 계열인지 판별하기 위해 termio.h 와 termios.h 헤더 파일 및 터미널 인터페이스를 검사(Probe)합니다. 하지만 Tmux 내부(세션 안)에서 컴파일을 진행할 경우 , Tmux가 제공하는 PTY(Pseudo-Terminal) 환경과 TERM=screen 등의 특수한 환경 변수 영향으로 인해 Autoconf가 터미널 인터페이스를 검출하는 과정에서 오동작을 일으킵니다. 그 결과, 실제 시스템 조건과 무관하게 설정 에러를 발생시키게 됩니다. 2. 왜 make clean 으로는 해결되지 않을까? 일반적인 개발 과정에서는 빌드가 꼬였을 때 make clean 을 실행하곤 합니다. 하지만 make clean 은 컴파일된 오브젝트 파일이나 바이너리( .o 파일 등)만 삭제할 뿐, Autotools가 시스템 환경을 탐색한 결과로 남긴 캐시( config.cache 또는 내부 매크로 변수)나 설정 파일들은 그대로 유지 합니다. 일반적인 상황에서는 시스템의 하드웨어/OS 정보가 바뀌지 않기 때문에 이 잔여물이 문제가 되지 않습니다. 그러나 Tmux나 Screen 같은 터미널 멀티플렉서 환경에서 탐색된 왜곡된 정보가 캐시에 박혀버리면, 나중에 Tmux 외부(일반 터미널)로 나와서 빌드를 시도해도 이전의 오염된 캐시 때문에 계속해서 오류가 발생하게 됩니다. 3. 해결 방법 이 문제를 해결하기 위해서는 반드시 Tmux 외부 환경 에서 기존의 오염된 설정 파일을 ...

이번에 docker라는 것을 처음 깔아보았다. 이제 길을 찾아볼까..




이런 것을 제공하지 않더라도, linux에서는 chroot로 비슷한 흉내는 낼 수 있었던 것 같은데,

2010년인가 cgroup이라는 기술(?현재 위키로 배우는 중)이 커널에 포함되고 
간편하게 자원을 분리할 수 있게 되었나보다. 


그러다 보니 어제 보던 Xdmx 관련한 문서를 또 보게 된다.
그 와 관계해서 xhost라는 툴을 열심히 삽질 했는데 관련한 부분이 또 나온다. 

docker는 그걸 간편하게 해주고, github과 같은 저장소로 특정 어플리케이션들을 안정적으로 구동할 수 있는 환경들을 모아 놓고, 사용하게 해주는 툴인듯 하다. 

그러고 나서는 docker에 올라간 프로세스는 xhost를 통해, 자원을 낭비하지 않고, 직접 local X . server display에 접근해서 gui 정보를 통신하는 듯 하다. 

먼가 굉장히 독특하다. 


내가 계속 삽질한 sun grid engine도 ubuntu에서 깨진 의존성(특정 라이브러리 하나가 어떻게 되서 실행이 불가능한 상황)도 쉽게 해결될 것 같다. 

하지만 내가 이것에 관해 수없이 구글링 했지만 docker나 비슷한 놈들을 추천해준 놈이 없는 걸 봐서, 기대는 어렵지만 그렇다면야 다른 배포판 redhat 계열등으로 테스트하면 되는 친구가 하나는 있을테니 내가 이쪽에 선두주자가 될 수도 있을 것이다. 

연구실에 남는 컴퓨터들이 정말 오래들 되었고, 하나하나씩 죽어간다. 수명이 10년이 넘은 친구도 있고,  gtx480달고 있던 컴퓨터도 파워가 죽을려고하고, 메인보드도 오늘내일 하고, gtx480은 탄내가 나는 상황이다 . 이놈은 상대적으로 젊은 놈인데도 이러는 것 보면,

연구실 컴퓨터들은 계속 죽어갈 텐데, 그래도 살아있는 동안에는 계산용으로 가치가 있다. 

많은 시간을 필요로 하는 작업들, 여러 ensemble data가 필요해서 반복적으로 돌리고 내가 까먹었을 때, 찾을 수 있는 data를 만들친구로 변환을 할 필요가 있다. 

결국은 sge를 깔아서 중앙에서 이들을 통제하는 환경을 만들 필요가 있다. 
분명히 소규모 환경에는 sge를 대체할 만한 방법이 많다. 

하지만 제대로 리소스 관리해주고 job queue를 만들어 미리 할 일을 넣어주고해서 최고의 효율을 계속 발휘해주기까지는 어렵기에 이 시스템을 구축하려고 여러번 시도했다. 

이번에는 성공하려나, 일단 이렇게 하기로 결심하고 나중에 블로그 글을보고 시도를 해야겠다. 


일단 docker를 통해 한글 2008체험판을 까는 것을 성공했다. 
이전에 깔고 실행할 때마다, 없다고 요동치는 라이브러리들을 직접 떠먹여가며 실행한 적이 있지만, 다시 시도했을 때는 그렇지 않았다. 

내가 시도를 하는 상황들이 다 다르기에 그럴 것이다. 다양한 상황에서 원하는 결과를 매번 같이 낼 수 있다는 것은 상당한 축복이다. 
이 것을 가지고 할 수 있는 일이 많을 것 같다. 

wine과 같은 툴도 playonlinux로 통제해서 실행하는 방법으로 수많은 윈도우 프로그램을 쉽게 실행시킨다. 그래도 부족한 부분이 있다. 이 부분은 docker나 cgroup기술을 사용하는 친구들을 어떻게 조합하면 누군가 한번만 성공해도 모두에게 동일한 방법을 제공할 수 있을 것 같으데, 상당히 흥미롭다. 

댓글