기본 콘텐츠로 건너뛰기

추천 가젯

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 외부 환경 에서 기존의 오염된 설정 파일을 ...

Image Compositing 정리. 1 (Screen, Multiply) 스크린, 곱하기


Screen은  검은색 배경으로 된 VFX를 합성할 때 사용되고는 한다. 

공식상, 검은색의 레이어는 원본의 색을 그대로 노출하고, 흰색의 레이어는 완전히 (RGB  각 값도 마찬가지)  아래의 값을 지워버린다. 

RGB, 원색 레이어를 통해 해당 색의 보색에 대한 필터로 작용할 수 있다. 

중간단계에서 보이는 부분이 재미있는데, 레이어의 색상으로 부터 최대값까지 색상을 압축하면서, 뒷면의 색상차는 그대로 보여줄 수 있다. 

24bit(8bit rgb) 이기 때문에 계단 현상은 생길 수 있으나, 뒷배경을 보이면서 오버레이어의 밝기 까지 보여 줄 수 있기 때문에 아주 유용하게 사용된다. 

인터넷에 있는 번개, 폭발 연기 등의 프리소스를 사용하여 오버레이어의 콤포지터를 Screen으로 사용하도록 하자. 


곱하기 효과는 Screen과는 반대로 작용한다. 흰색일 때는, 베이스 컬러를 그대로 보여주고, 검정색일 때는 검은색이 되어버린다. 

레이어의 색상을 최대값으로  검정색으로부터 베이스의 색상을 압축하여 표현된다.

R,G,B 의 원색을 사용하여 특정 채널만 뽑는데만도 사용할 수 있다. 

배경이 흰색이 소스를 합성할 때 사용하면 좋다.  그러나 배경이 흰색인 소스의 합성은 주로 Y-채널을 조작해  Alpha로 사용하는 Luma Key를 많이 사용한다.    이건 뭔가 사람의 눈과 관련이 있을 것으로 보인다. 빛이 비춰 밝아진 물체를 구분하기는 쉽지만, 특정 부분만 어두워 지는것을 구분하는 일이 더 적어 질 것 같기는 하다. 

댓글