컴퓨터 공학 전공으로 졸업하고, 어언 6년이 지났건만.. 
아직 기초가 부족한 부분이 많은 것 같습니다.

학부 때는 단순히 윈도우 환경에서 Visual Studio나 Eclipse 프로그램을 사용하여
자연스런 컴파일 환경을 통해 프로그래밍 언어를 습득하기에만 정신이 없었고...

모바일 폰 개발 회사에서 재직하는 동안에도 선배들이 만들어놓은 개발 환경을 그대로 이용만 하여,
프로그래밍을 해왔기에..  개발 환경에 대해 제대로 개념을 익히는 시간이 거의 없었습니다..

학부 때 잠시나마 배웠던, 컴파일에 대한 개념도 가물가물 해졌습니다. ㅜㅜ (밑에 간단 정리..)

c언어 코딩 부터 실행파일까지의 기본 순서 : *.c -> *.s -> *.o -> *.exe or *.elf 등등

*compiler : 고수준코드(*.c)에서 목적 코드(*.o)로 옮기는 과정을 통합하여 수행하는 프로그램을 가리킨다.

*좁은 의미의 compiler : 고수준 코드(*.c)를 저수준 코드 (*.s)로 옮기는 과정을 수행하는 프로그램.

*assembler : 저수준 코드(*.s)를 목적 코드 (*o)로 옮기는 작업을 수행하는 프로그램.

*linker : 컴파일러가 만든 목적 코드 (*.o)와 library를 모아 기계어인 실행파일 (*.elf or *.exe)로 변환하는 프로그램.

사실 SW 개발자 입장에서 개발 환경은 한 번 셋팅 해놓으면, 크게 신경을 쓰지 않기에 지나치기 쉬운 것 같습니다.

임베디드 SW를 만드는 업을 해왔지만, 주로 윗단을 (Application 단 + Framework 단) 다루다가,
최근에 아랫단를 (펌웨어) 개발해야 할 기회가 왔기에.. 다시금 개발환경에 대해 파악해보려 합니다.

모바일 폰에 사용되는 칩셋(CPU)의 Core는 ARM을 이용합니다.

그리고 펌웨어 개발 환경은 대부분 리눅스 커널 환경을 사용하기에 이에 대해 잠시 집고 가볼까 합니다.

잘 정리해 주신 블로거님이 계시기에 아래에 퍼왔습니다.

일단 결론을 말씀드리자면, 아래와 같습니다.

1. 리눅스 환경에서 개발 시에는 거기서 제공하는 tool chain을 다운로드하여 사용
   (apt-get 툴을 이용해 필요한 버전의 툴 체인 설치)
2. 윈도우 환경에서 개발 시에는 주로 Cygwin(gcc 제공)을 이용하게 됩니다.

** ARM 타깃용 크로스 툴 체인 --> http://linaro.org 참조

우리가 윈도우즈 환경에서 리눅스 ARM 용 프로그램을 빌드하기 위해서는, 그에 맞는 바이너리를 생성해 줄 수 있는 환경( 컴파일러, API 등 )을 구성할 필요가 있다. 윈도우즈에서 이를 가능하게 해 주는 것이 POSIX 기반의 시그윈 개발 환경이다. 
--> Cygwin 에서는 Windows에서 사용가능한 리눅스 환경의 API들을 제공하고,
     tool chain (ARM용 gcc 크로스 툴 체인, git 등)을 제공합니다.

우리는  시그윈 환경을 이용해 리눅스 ARM 용 프로그램을 빌드하고, 그것을 안드로이드 장치로 복사하고 설치하게 된다. 이것이 윈도우즈와 리눅스 간의  크로스 플래폼 개발이다. 안드로이드 SDK 를 사용하게 되면 자바 바이트 코드( 플래폼에 독립적인 중간 코드 )를 생성하기 때문에 빌드 환경이 중요하지 않지만, 안드로이드 NDK 는 실제 리눅스 API 를 이용하고 기계어로 컴파일하기 때문에 반드시 올바른 환경에서 개발해야만 한다.

좀 더 자세한 내용은 아래 펌 참고...

http://lifeisforu.tistory.com/132  (안드로이드 NDK 개발환경 예시)

NDK 로 개발을 한다는 것이 의미하는 바가 무엇인지 생각해 볼 필요가 있다. 많이들 알고 있는 사실이겠지만, 어떤 프로그램이 어떤 머신에서 실행되기 위해서는 해당 머신에 맞는 실행가능한 파일( executable )을 만들어야만 한다. 그것이 소위 우리가 알고 있는 '컴파일'과 '링크'라는 작업이다. 이 컴파일 작업과 링크 작업을 합쳐서 '빌드'라고 표현한다.

우리가 열심히 코딩한 라인들은 어셈블리어로 변환되고, 이 어셈블리어들은 다시 기계어로 변환된다. 그리고 CPU 는 이 기계어를 마이크로 명령어로 나누어서 프로그램을 실행하게 된다. 그런데 이 CPU 가 어떠한 명령어 집합 구조( Instruction Set Architecture, ISA )를 제공하느냐에 따라서 다른 기계어를 만들어야 하기 때문에, 프로그램을 빌드할 때는 해당 CPU 에 맞는 구성을 만들어야 한다. 예를 들어 CPU 가 x86 ISA 를 제공한다면 x86 에 맞는 빌드 구성을 해야 하고, CPU 가 x86/64 를 제공한다면 거기에 맞는 빌드 구성을 만들어야 한다.

자 우리가 NDK 를 통해 만든 바이너리를 실행할 플래폼의 환경은 어떠한가? 일반적으로 현재 안드로이드 OS 가 돌아 가는 환경은 ARM 코어를 사용하는 리눅스 환경이다. 이는 어떠한 사실을 내포할까?

• 우리가 C/C++ 응용프로그램을 개발할 때 CreateFile() 과 같은 Win32 API 를 사용할 수 없다.

• Visual Studio 를 이용할 수 없다. --> VC++ 컴파일러를 사용할 수 없다.

사실 Visual Studio 의 컴파일러를 GCC( GNU Compiler Collection ) C++ 컴파일러로 연결해 놓고 개발할 수는 있을 것이다. 하지만 기본 환경 자체가 Win32 서브시스템과 x86 혹은 x86-64 아키텍처를 위한 개발에 최적화되어 있으므로 참 어려운 일이 될 것이다. 구글링을 해 보면 여러 가지 자료들이 나오기는 하는데 얼마나 편한 지는 잘 모르겠다. 어쨌든 우리는 리눅스 OS 를 기반으로 ARM ISA 에 맞춰서 빌드해야만 하는 상황이고, 윈도우즈 환경에서 이를 가능하게 만들 수 있는 방법을 찾아야만 한다. 

이때 우리에게 한 줄기 빛을 비춰주는 존재가 있으니, 그것이 바로 시그윈이다.

Cygwin 이란 무엇인가?

일단 시그윈 공식 사이트의 설명을 인용해 보도록 하겠다. 출처 : http://cygwin.com/index.html

시그윈은 :

• 윈도우즈를 위해 리눅스처럼 느껴지는 환경을 제공하는 도구들의 집합이다.

• 많은 리눅스 API 기능을 제공하는 리눅스 API 레이어로서 동작하는 DLL( cygwin1.dll )이다.

그리고 다음과 같이 착각하지 말라고 경고하고 있다.

시그윈은  :

• 윈도우즈 상에서 네이티브 리눅스 앱들을 실행하는 방법이 아니다. 당신이 윈도우즈 상에서 프로그램을 실행하기 원한다면, 소스로부터 앱들을 리빌드해야만 한다.
• signal, pty 등과 같은 유닉스 기능들을 인지하는 네이티브 윈도우즈 앱들을 마술처럼 만들어 주는 방법이 아니다. 다시 말하지만, 당신이 시그윈 기능의 이점을 취하기 원한다면, 소스로부터 앱들을 리빌드할 필요가 있다.

앞에서도 언급했지만 특정 CPU 아키텍처에 대해 리눅스용으로 빌드된 프로그램은 윈도우즈에서 실행될 수 없다. 당연히 윈도우즈 환경에 맞는 구성으로 다시 빌드해야만 한다. 시그윈은 크로스 플래폼 개발을 가능하게 해주는 환경일 뿐이지, 에뮬레이터가 아니라는 것을 명심해야만 한다.

Cygwin 의 작동 원리.

그렇다면 시그윈은 어떻게 해서 리눅스와 같은 개발 환경을 지원하게 되는 것일까?

여러분은 Visual Sutdio 를 통해 프로젝트 설정을 하다가 '서브시스템' 이라는 항목을 본 적이 있을 것이다. 윈도우즈는 여러 개의 서브시스템을 가지고 있는데, 우리가 주로 사용하는 것이 Win32 서브시스템이다. 아래 그림은 Windows NT 의 시스템 아키텍처에서의 POSIX 서브시스템을 보여 주고 있다.

윈도우즈 NT 시스템 아키텍처( 출처 : 위키피디아 )

이 POSIX 라는 것은 Portable Operating System Interface 의 약자로 IEEE 가 운영체제 간의 호환성을 유지하기 위해서 제정한 표준이다.

POSIX( 대충 '파직스'라고 발음됨 )는 "Portable Operating System Interface" 의 머리글자들이며, 운영체제 간의 호환성을 유지하기 위해서 IEEE 에 의해 제정된 표준 패밀리이다. POSIX 는 다양한 유닉스 및 다른 운영 체제들 간의 소프트웨어 호환성을 위해 응용프로그램 인터페이스( API )와 명령줄 쉘, 그리고 유틸리티 인터페이스들을 정의한다.

중략...

유닉스 같은 운영 체제 환경을 위한 POSIX 명세는 원래 코어 프로그래밍 인터페이스를 위한 단일 문서로 구성되어 있었지만, 결국에는 19 개의 분리된 문서로 늘어 났다( 예를 들면 POSIX1, POSIX2, 등 ). 표준화된 사용자 명령 줄과 스크립팅 인터페이스들은 Korn Shell 에 기반했다. awk, echo, ed 등을 포함하는 많은 사용자 수준 프로그램, 서비스, 유틸리티들도 표준화되었으며, 기본적인 I/O( 파일, 터미널, 네트웤 )을 포함하는 프로그램 수준 서비스들도 포함한다. POSIX 는 표준 스레딩 라이브러리 API 도 정의하는데, 이는 현대의 거의 대부분의 OS 에 의해서 지원된다. 요새는 대부분의 POSIX 파트들이 하나의 IEEE Std 1003. 1-2008 표준에 포하모디었으며, 이는 POSIX 1-2008 로 알려져 있다.

하략...

- 출처 : 위키피디아, POSIX

OS/2 라는 것은 MS 와 IBM 이 초기에 제작한 운영체제로 요새는 별로 의미가 없으므로 관심있는 분들은 위키피디아의 OS/2 라는 글을 따로 읽어 보기 바란다.

POSIX 를 지원하는 OS 리스트는 다음 링크의 'POSIX-oriented operating systems' 절에서 찾아 볼 수 있다 : 위키피디아, POSIX. GNU/Linux 같은 경우에는 POSIX 에 대해 '거의 대부분의 호환성' 을 가지고 있다. 시그윈은 POSIX 에 대해 '많은 호환성' 을 가지고 있다고 표현되고 있다. 즉 안드로이드 시스템의 기반이 되는 리눅스가 POSIX 를 거의 완벽하게 지원하고 있기 때문에, 우리는 윈도우즈 상에서 시그윈을 통해 거기에 맞는 환경을 구성할 수 있는 것이다.

위에서 윈도우즈의 POSIX 서브시스템에서 언급을 했는데 여기에서 윈도우즈의 POSIX 를 언급한 것은 그냥 예를 든 것 뿐이다. 시그윈이 윈도우즈의 POSIX 서브시스템의 레이어라는 이야기는 아니다. 왜 그럴까? 윈도우즈의 POSIX 서브시스템은 POSIX 표준을 제대로 지키고 있지 않기 때문이다. 

시그윈은 윈도우즈의 POSIX 와는 개별적으로 동작하는 개발환경이다. 시그윈 환경, 시그윈 서브시스템, 시그윈 플래폼 등의 용어를 사용해도 무방하지 않을까 싶다. 시그윈이 윈도우즈의 POSIX 서브시스템의 레이어로서 동작하지 않는 이유는 다음 글을 보면 좀 더 이해가 가지 않을까 싶다 : The Sad History of the Microsoft POSIX Subsystem. 아래에 일부만 인용해 보았다. 요약하면 윈도우즈 POSIX 가 허접(?)이란 것과 XP 부터는 POSIX 서브시스템을 지원하지 않는다는 것이다. 그 뒤의 이야기가 쭉 나오는데 다 읽어 보지는 못했다.

윈도우즈 NT 가 처음 개발되고 있었을 때, 목표 중의 하나는 커널을 프로그래밍 인터페이스와 분리하는 것이었다. NT 는 원래 OS/2 를 성공시키기 위한 것이었지만, 마이크로소프트는 윈도우즈 3.x 응용프로그램들을 실행하기 위한 호환성을 포함시키고, 방위산업 시장에 판매하기 위한 1980 년대 DoD( 국방성 ) Orange Book 과 FIPS 명세들을 만족시키기 원했다. 결과적으로 윈도우즈 NT 는 복잡한 자유재량에 의한 접근 제어 기능을 가진 멀티유저 플래폼으로서 개발되었으며, 하이브리드 마이크로커널 3 유저랜드¹ 환경들로서 구현되었다 :

• Windows( Win32 )
• OS/2
• POSIX

마이크로소프트는 Win32 문제를 가지고 IBM 과 다퉜으며, NT 프로젝트는 OS/2 와 갈라섰다. 팀의 초점은 Win32 로 이동했다. 그래서 Win32 API 를 호스트하는 Client Server Runtime Subsystem( CSRSS ) 은 의무적이 되었으며, OS/2 와 POSIX 서브시스템이 실제로 완료되지 않았음에도 불구하고 그것들은 윈도우즈 NT 부터 윈도우즈 2000 까지 5 개의 버전에 포함되었다. OS/2 서브시스템은 단지 OS/2 1.0 명령줄 프로그램들만을 실행할 수 있으며, presentation manager 에 대한 지원이 존재하지 않았다. POSIX 서브시스템은 POSIX.1 명세를 지원했지만, 모든 종류의 쉘이나 유닉스 같은 환경을 제공하지 않았다. Win32 가 윈도우즈 95 의 형태에서 성공하면서, OS/2 와 POSIX 서브시스템의 개발은 중단되었다. 그것들은 윈도우즈 XP 와 윈도우즈 서버 2003 에서 완전히 죽고 사라졌다.

반면에 Softway Systems 는 1996 년 쯤에 OpenNT 라고 불리는 유닉스-윈도우즈 NT 간 포팅 시스템을 개발했다. OpenNT 는 NT POSIX 서브시스템 상에서 빌드되었지만, 그것에 살을 붙여 이용할 수 있는 유닉스 환경을 제공했다. 이는 유닉스 시스템이 매우 비싸진 시점이었다. Softway 는 OpenNT 를 사용해서 US Federal agency 들을 위한 여러 유닉스 응용프로그램들을 윈도우즈 NT 로 변경했다. 1998 년에 OpenNT 는 Interix 라고 이름을 바꿨다. Softway Systems 는, 마이크로소프트 POSIX 서브시스템이 지원하지 않았던 시스템 호출을 구현하고, 풍부한 libc,  파일 시스템에 대한 single-rooted view, 그리고 실용적인 gcc 를 개발하기 위해, 최종적으로 NT POSIX 서브시스템에 대한 완전한 대체물을 만들었다.

하략...

위키피디아에 의하면 Windows Server 2003 R2 부터는 사실은 Interix 의 변형인 SUA( Subsystem for UNIX-based Applications )를 통해서 POSIX 를 지원하고 있다고 한다. 이것은 SFU( Windows Services for UNIX )라고 불리기도 한다. Windows Vista 및 Windows 7 의 Enterprise 에디션과 Ultimate 에디션도 SUA 를 포함하고 있다고 한다. 자세한 내용은 Windows Services for UNIX 를 참조하라.

결론.

우리가 윈도우즈 환경에서 리눅스 ARM 용 프로그램을 빌드하기 위해서는, 그에 맞는 바이너리를 생성해 줄 수 있는 환경( 컴파일러, API 등 )을 구성할 필요가 있다. 윈도우즈에서 이를 가능하게 해 주는 것이 POSIX 기반의 시그윈 개발 환경이다. 

우리는  시그윈 환경을 이용해 리눅스 ARM 용 프로그램을 빌드하고, 그것을 안드로이드 장치로 복사하고 설치하게 된다. 이것이 윈도우즈와 리눅스 간의  크로스 플래폼 개발이다. 안드로이드 SDK 를 사용하게 되면 자바 바이트 코드( 플래폼에 독립적인 중간 코드 )를 생성하기 때문에 빌드 환경이 중요하지 않지만, 안드로이드 NDK 는 실제 리눅스 API 를 이용하고 기계어로 컴파일하기 때문에 반드시 올바른 환경에서 개발해야만 한다.

이제 시그윈이라는 것의 정체에 대해 어느 정도 이해할 수 있게 되었을 것이라 생각한다. 그리고 시그윈을 통해 뭔가를 빌드한다는 것의 의미에 대해서 이해할 수 있게 되었을 것이라 생각한다.