|| C 소스의 전체 컴파일 과정

gcc는 GNU에서 만든 C컴파일러라고 말하지만 사실 컴파일러 드라이버이다.

gcc는 실제 컴파일 과정을 담당하지 않고 전처리기와 C 컴파일러, 어셈블러, 링커를 각각 호출해 주는 역할만 한다.

이렇게 각각의 컴파일 과정에 필요한 명령을 순차적으로 호출해 주는 것을 컴파일러 드라이버라고 한다.

그럼 진짜 컴파일러는 어디에 있을까?

[oneone@study study]$ /usr/libexec/gcc/i686-redhat-linux/4.4.4/

cc1       cc1plus   collect2  f951

<컴퓨터 구조> 시간 떄 배운 개념이 나옴. 따로 설명안함

어셈블리어(instrution set) 와 기계어 개념. 모르면 공부하거나 패스하길.

[like.c 소스]

다음 명령으로 컴파일 하면 like실행 파일을 얻을 수 있다.

[oneone@study study]$ gcc -g -o like like.c

문서 정보

원문: http://www.linuxjournal.com/article/6463 
출처 : http://blog.naver.com/simz/20024938289 
저자: Sandeep Grover, 2002.11.26 
정리: 이동우(leedw at ssrnet.snu.ac.kr), 2005.11.26

Linkers and Loaders

링킹(Linking)이란 코드와 데이타들을 한데 묶어 메모리에 로드될 수 있는 하나의 실행파일 형태로 만드는 작업을 말한다. 링킹은 compile time, load time(로더에 의해) 혹은 run time(어플리케이션에 의해)에도 이루어질 수 있다. 링킹의 유래는 1940년까지 거슬러 올라가는데 당시에는 수작업으로 이루어졌다고 한다. 현재는 링커(Linker)가 있어서 동적으로 링크되는 공유 라이브러리(shared library)와 같은 복잡한 작업을 수행해 주고 있다. 이 문서에서는 재배치(relocation)부터 심볼 해석(symbol resolution)까지 이르는 링킹의 각 측면들을 간단히 살펴보도록 하겠다. 편의상 x86 아키텍쳐에서 구동되는 Linux 기반의 ELF 포맷과 GNU 컴파일러(gcc)/링커(ld)에 촛점을 맞추어서 논의하도록 하겠다. 그러나 링킹의 기본 컨셉은 프로세서나 운영체제, 오브젝트 포맷과 상관없이 모두 동일하다고 보면 된다.

다음과 같이 a.c와 b.c 두 개의 프로그램이 있다고 생각해 보자. 쉘에서 두 코드들을 gcc에 입력할 때 다음과 같은 작업들이 수행된다.

· a.c에 대해 전처리기(preprocessor)가 실행되어 전처리기 중간 파일(a.i)이 생성된다.

· a.i에 대해 컴파일러가 실행되어 a.s라는 어셈블러 코드가 생성된다.

· a.s에 대해 어셈블러가 실행되어 a.o라는 object 파일이 생성된다.

cpp, cc1과 as는 각각 GUN 전처리기, 컴파일러, 어셈블러로서 표준 GCC 배포본에 들어있는 툴들이다.
위의 3단계 과정이 다시 b.c에 적용되어 b.o가 생성이 된다. 이제 링커는 2개의 오브젝트 파일(a.o, b.o)을 입력받아 최종 실행파일을 만들게 된다.

최종으로 생성되는 실행파일(a.out)은 이제 메모리에 로드될 수 있다. 실행파일을 실행하기 위해선 shell prompt 상에서 파일 이름만 타이핑해 주면 된다.

쉘은 로더 함수를 호출하게 되고 로더는 실행파일 a.out속에 있는 코드와 데이타를 메모리에 복사한다. 그리고 프로그램의 시작 주소로 제어권을 넘겨주게 된다. 로더는 execve라 불리는 프로그램으로서 실행파일속에 들어 있는 코드와 데이타를 메모리에 로드하고 코드의 첫번째 주소에 위치한 instruction으로 점프하여 프로그램을 실행시키는 작업을 수행한다. 
a.out는 a.out 오브젝트 파일들의 "Assembler OUTput"이라는 의미에서 명명되었다.. 이후로 오브젝트 포맷은 변해갔지만 그 이름은 계속 사용되었다.

링커와 로더는 여러 유사한, 그러나 개념적으로는 다른 작업들을 수행한다.

· 프 로그램 로딩(Program loading). 이것은 하드 디스크에 저장되어 있는 프로그램 이미지를 메인 메모리에 복사하여 실행상태로 만드는 것을 말한다. 어떤 경우에는 프로그램 로딩은 디스크 페이지에 가상 주소를 매핑하거나 저장 영역을 할당하는 것도 포함된다.

· 재 배치(relocation). 컴파일러와 어셈블러는 입력받은 각 모듈에 대해 0번지로 시작하는 오브젝트 코드를 생성한다. 재배치는 같은 타입의 모든 section을 하나의 단일 section으로 통합함으로써 프로그램의 각 파트에 로딩 주소를 할당하는 작업이다.

· 심 볼해석(Symbol resolution). 하나의 프로그램은 여러 서브 프로그램으로 구성되어 있다. 하나의 서브 프로그램이 다른 프로그램을 참조할 때 심볼이 사용된다. 링커가 하는 일은 심볼의 위치를 기억해 두었다가 심볼을 사용하는 호출모듈의 오브젝트 코드를 패치하여 심볼 참조를 해석(resolve)한다.

링커와 로더의 기능 사이에는 겹치는 부분이 상당히 많다. 한가지 생각해 볼 수 있는 방법은, 로더는 프로그램 로딩을 수행하고, 링커는 심볼 해석(symbol resolution)을 담당며 둘 다 재배치(relocation)을 할 수 있다는 것이다.

오브젝트 파일은 다음과 같이 3개의 형태로 나뉜다.

· 재배치 가능한 오브젝트 파일(relocatable object file). compile-time에 다른 재배치 가능한 오브젝트 파일과 통합할 수 있어 하나의 실행파일이 생성될 수 있는 형태의 바이너리 코드와 데이타를 포함한다.

· 실행 오브젝트 파일(executable object file). 메모리에 직접 로딩되어 실행될 수 있는 형태의 바이너리 코드와 데이타를 포함한다.

· 공유 오브젝트 파일(shared object file). load-time이나 run-time에 동적으로 메모리에 로드되고 링크될 수 있는 특수한 타입의 재배치 가능한 오브젝트 파일.

컴파일러와 어셈블러는 재배치 가능한 오브젝트 파일(또한 공유 오브젝트 파일도)을 생성한다. 링커는 그러한 오브젝트 파일을 통합하여 실행파일을 생성한다. 
오 브젝트 파일은 시스템에 따라 각기 다른 형태를 가지는데 최초 unix 시스템에서는 a.out 포맷을 사용했었다. system V의 초기 버전에서는 COFF(common object file format)을 사용했고 windows NT는 PE(portable executable)라 불리는 COFF의 변종을 사용한다. IBM은 자체적으로 설계한 IBM 360 포맷을, Linux나 Solaris와 같은 현대 unix 시스템은 UNIX ELF(execuatble and linking format)를 사용한다. 
이 문서에서는 주로 ELF에 대해 촛점을 두겠다.

표1. 전형적인 재배치 가능한 ELF오브젝트 파일 형식

위 그림은 전형적인 ELF relocatable object file의 포맷을 보여주고 있다. ELF 헤더는 4바이트 magic string('0x7f', 'E', 'L', 'F')으로 시작된다. ELF relocatbale object file 내에 있는 여러 section들을 살펴보면 다음과 같다.

· .text : 컴파일된 프로그램의 기계어 코드

· .rodata : 읽기 전용 데이타(read-only data). printf 구문에 들어가는 format string등이 이 영역에 저장된다.

· .data : 초기화된 전역 변수가 저장되는 영역

· .bss : 초기화되지 않은 전역 변수가 저장되는 영역. BSS는 "Block Storage Start"의 약자이다. 이 section은 실제로는 오브젝트 파일내에서 아무 공간도 차지하지 않고 있다.

· .symtab : 프로그램 내에서 정의되거나 참조되고 있는 전역 변수와 함수에 대한 정보를 담고 있는 심볼 테이블. 이 테이블에는 로칼 변수에 대한 정보는 담고 있지 않은데 이는 스택이 그 정보를 담고 있기 때문이다.

· .rel.text : 링커가 이 오브젝트 파일과 다른 오브젝트 파일을 combine할 때 .text 내에서 변경되어야 할 위치들의 리스트를 담고 있는 영역.

· .rel.data : 현재 모듈에서 참조만 되고 정의되어 있지 않은 전역 변수의 재배치 정보

· .debug : 지역 및 전역 변수를 엔트리로 가지는 디버깅 심볼 테이블. 이 섹션은 컴파일러 옵션 -g가 주어졌을 때 생성된다.

· .line : 원본 c소스 프로그램의 라인번호와 .text 섹션에 있는 머신 코드간의 매핑 정보. 디버거 프로그램에서 이 정보를 사용한다.

· .strtab : .symtab과 .debug 섹션에 있는 심볼 테이블들의 스트링 테이블

재배치 가능한 모든 오브젝트 파일에는 심볼 테이블과 그와 관련된 심볼들을 가지고 있다. 링커의 맥락으로 살펴보면 심볼은 다음과 같은 종류가 있다. 
· 입력 모듈에서 정의되어 있는 global symbol. 다른 모듈에서 참조할 수 있다. 일반 함수와 전역 변수가 여기에 속한다.

· 입력 모듈에서 참조하는 하고 있지만 다른 곳에 정의된 global symbol. extern으로 선언된 함수와 변수가 여기에 해당

· 입력 모듈에서 정의되어 해당 모듈에서만 배타적으로 참조할 수 있는 local symbol. 정적 함수와 정적 변수가 이 범주에 속한다.

링커는 입력으로 들어온 재배치 가능한 오브젝트 파일의 심볼 테이블에 있는 엔트리를 검색해서 심볼 참조(symbol reference)를 해석한다. local symbol은 한 모듈에서 다중으로 정의할 수 없기 때문에 local symbol의 해석은 간단한 편이다. 반면에 global symbol은 약간의 기교를 필요로 한다. 컴파일할 때 캄파일러는 각각의 global symbol을 '약'하게, 혹은 '강'하게 export할 수 있다. 함수와 초기화된 전역 변수들은 강한 무게로 export되는 반면 초기화 되지 않은 전역 변수들은 약한 무게로 export된다. 링커는 다음과 같은 규칙을 사용해 심볼을 해석하게 된다.

   1. 여러 개의 strong symbol은 허락되지 않는다.

   2. 하나의 strong symbol과 여러 개의 weak symbol이 주어질 때, strong symbol을 선택한다.

   3. 여러 개의 weak symbol이 있을 경우 그 중 아무거나 선택한다.

예를 들어, 다음과 같은 두 개의 프로그램을 링크시킬 경우 링커는 에러를 발생시키게 된다. 

/* foo.c */               /* bar.c */

int foo () {               int foo () {

   return 0;                  return 1;

}                          }

                           int main () {

                              foo ();

                           }

foo(전역 함수로서 strong symbol에 해당한다.)가 두 번 정의되어 있으므로 링커는 에러 메시지를 출력한다.

gcc foo.c bar.c

/tmp/ccM1DKre.o: In function 'foo':

/tmp/ccM1DKre.o(.text+0x0): multiple definition of 'foo'

/tmp/ccIhvEMn.o(.text+0x0): first defined here

collect2: ld returned 1 exit status

collect2는 링커 ld의 wrapper로서 gcc에 의해 호출된다.

정적 라이브러리(static library)는 비슷한 유형의 오브젝트 파일들을 모아 놓은 것이다. 이 라이브러리는 아카이브(archive) 형태로 디스크에 저장되어 있다. 아카이브에는 검색을 빠르게 하기 위해 디렉토리 정보도 포함되어 있다. ELF archive는 매직 스트링 "!<arch>\n"로 시작한다. 
정적 라이브러리는 컴파일러 툴(링커)에 인자로 넘겨진다. 유닉스 시스템에서는 libc.a는 대부분의 프로그램이 사용하는 printf, fopen를 포함한 모든 c라이브러리 함수를 포함하고 있다.

libm.a는 표준 수학 라이브러리(math library)로 sqrt, sin, cos등등의 수학 함수가 정의된 오브젝트 모듈들을 포함하고 있다.

static library를 사용해 심볼 해석을 진행하는 과정에서 링커는 커맨드 라인에서 입력으로 들어온 인자의 왼쪽부터 오른쪽 방향으로 재배치 가능한 오브젝트 파일과 아카이브를 검색한다. 이 검색중에 링커는 실행 파일로 만들어질 재배치 가능한 오브젝트 파일의 묶음인 O집합, 해석되지 않은 심볼 리스트를 담고있는 U집합, 입력 모듈에서 정의된 심볼들을 나타내는 D집합을 관리하게 된다. 초기에는 이 세개의 집합은 비어있게 된다. 
· 링커는 커맨드 라인에서 입력으로 들어온 인자가 오브젝트 파일인지 아카이브인지를 결정한다. 만약 입력 모듈이 재배치 가능한 오브젝트 파일이라면 링커는 그것을 O집합에 추가하고 U와 D를 업데이트한 후 다음 입력 파일로 진행한다.

· 만 약 입력 모듈이 아카이브라면 아카이브를 구성하는 모듈 멤버들을 쭉 검색해서 U집합에 들어있는 해석되지 않은 심볼과 매치되는지 살펴본다. 만약 아카이브 멤버중에서 해석되지 않았던 심볼을 정의해 놓은 모듈이 있다면 그 모듈은 O리스트에 추가되고 U와 D는 업데이트된다. 이 과정은 모든 오브젝트 파일 멤버들에게 행해진다.

· 입력 모듈에 대해 위와 같은 두 단계가 모두 행해진 후 만약 U집합이 비어있지 않다면 링커는 에러를 리포팅하고 종료한다. U집합이 비어있다면 O집합에 있는 오브젝트 파일들은 merge되고 재배치되어 실행파일이 만들어진다.

이 과정을 통해 왜 정적 라이브러리가 링커 커맨드의 마지막에 위치하는지 알 수 있게 된다. 두 개의 라이브러리가 서로 순환적 의존 관계에 있는 경우에는 특별히 주의를 기울여야 한다. 커맨드 라인에 라이브러리를 입력할 때 심볼들이 아카이브의 멤버 라이브러리에 의해 참조될 수 있도록 순서를 가지고 입력되어야 한다. 심볼이 정의된 라이브러리가 그것을 참조하는 라이브러리보다 앞선 순으로 입력되어야 하고 만약 해석안된 심볼이 한 개 이상의 정적 라이브러리 모듈에서 정의되어 있을 때는 커맨드 라인에서 첫번째로 입력된 라이브러리의 정의를 따르게 된다.

링커가 심볼의 해석을 모두 끝내게 되면 각각의 심볼 참조는 오직 하나의 심볼 정의를 갖게 된다. 이 시점에서 링커는 다음과 같은 두 단계의 재배치(relocation) 작업을 시작하게 된다.

· section 과 심볼 정의(symbol definition)들을 재배치한다. 링커는 같은 타입의 섹션들을 묶어 하나의 새로운 섹션으로 통합한다. 예를 들어 링커에 입력된 재배치 가능한 파일들에 있는 각각의 .data 세션을 하나의 단일한 .data 섹션으로 머지하여 최종 실행파일을 생성한다. .code 섹션에도 같은 작업이 수행된다. 그리고 링커는 이렇게 통합하여 생성된 섹션들과 입력 모듈에서 정의한 섹션들, 그리고 각각의 심볼들에게 run-time 메모리 주소를 할당한다. 이 단계가 끝나면 프로그램 내에 있는 모든 인스트럭션과 전역 변수들은 고유한 load-time 주소를 갖게 된다.

· section내에 있는 심볼 참조를 재배치한다. 링커는 이 단계에서 코드 및 데이타 섹션에 있는 모든 심볼 참조를 변경하여 심볼이 정의된 정확한 load-time 주소를 가리키게 만든다.

어셈블러가 unresolved 심볼을 만나게 되면 해당 오브젝트에 relocation entry를 생성하고 이를 .relo.text/.relo.data 섹션에 저장한다. relocation entry에는 해당 심볼의 참조를 어떻게 해석할 것인지에 대한 정보를 담고 있다. 전형적인 ELF relocation entry에는 다음과 같은 정보들로 구성되어 있다.

· Offset : 재배치 해야할 심볼 참조의 section offset. 재배치 가능한 파일에서 보면 이 값은 섹션의 시작부터 심볼 참조 위치까지의 바이트 옵셋 값이다.

· Symbol : 변경된 심볼 참조가 가리켜야할 심볼. 각각 재배치가 될 심볼 테이블의 인덱스라고 보면 된다.

· Type : 재배치 타입, 정상적인 경우 프로그램 카운터(PC) 상대 주소 방식(PC-relative addressing)을 의미하는 "R_386_PC32"이다. "R_386_32"는 절대 주소 방식(absolute addressing)을 의미한다.

링커는 재배치 가능한 오브젝트 모듈에 있는 모든 relocation entry를 조사해서 unresolved symbol을 type에 따라 재배치하게 된다. 가령 심볼이 "R_386_PC32" 타입인 경우, 재배치 주소는 S+A-P로 계산이 이루어지고 "R_386_32" 타입인 경우 S+A 식으로 계산이 된다. 여기서 'S'는 relocation entry의 심볼 값, 'P'는 section offset이나 재배치될 주소값(relocation entry에 저장된 offset값을 사용해 계산한다.), 'A'는 relocatable field의 값을 계산할 때 필요한 주소를 의미한다.

정적 라이브러리(static library)는 몇몇 심각한 단점을 가지고 있다. 예를 들어 printf나 scanf와 같은 표준 라이브러리 함수를 생각해 보자. 이런 함수들은 거의 모든 어플리케이션에서 사용하고 있다. 만약 시스템이 50-100개의 프로세스를 실행하게 되면 각각의 프로세스는 printf, scanf 함수가 구현된 실행 코드를 가지게 될 것이다. 이것은 중요한 메모리 공간을 차지하게 되는 원인이 된다. 반면 공유 라이브러리(shared library)는 이런 정적 라이브러리의 결함을 해결하고 있다. 공유 라이브러리는 run-time시 어느때나 임의의 메모리 주소에 로딩될 수 있는 object module로서 이미 메모리에서 실행중인 프로그램에 의해서 링크될 수 있다. 공유 라이브러리는 때때로 공유 오브젝트(shared object)라고도 불린다. 대부분의 unix 시스템에서는 이런 공유 오브젝트를 ".so" 접미사로 표기하지만 HP-UX에서는 ".sl"로, MS 시스템에서는 DLL(dynamic link library)로 표기하기도 한다. 
공유 오브젝트를 빌드하기 위해선 컴파일러에 특별한 옵션을 주어 실행시킨다.

이제 "a.o", "b.o"에 의존적인 메인 오브젝트 모듈 "bar.o"를 가정해 보자. 이 경우 링커는 다음과 같은 커맨드로 실행된다.

이 커맨드를 통해 load-time에 "libfoo.so"를 링크할 수 있는 형태의 "a.out" 실행파일이 생성된다. 이 "a.out"에는 공유 라이브러리를 링크했기 때문에 "a.o", "b.o"가 포함되어 있지 않다. 만약 공유 라이브러리 대신 정적 라이브러리를 포함했다면 그 2개의 오브젝트 모듈 코드가 모두 들어 있을 것이다. 
여기서 실행파일은 단지 "libfoo.so"의 데이타나 코드를 참조할 수 있도록 심볼 테이블 및 재배치 정보만 담고 있다가 run-time에 해석이 이루어진다. 따라서 "a.out"은 "libfoo.so"에 의존성을 가진 불완전한 실행파일이라고 할 수 있다. 또한 실행파일은 ".interp"라는 섹션을 가지고 있는데 여기에는 동적 링커(dynamic linker)의 이름이 포함되어 있다. 이것 또한 linux 시스템에 포함된 공유 오브젝트(ld-linux.so)이다. 그래서 실행파일이 메모리에 로딩될 때 로더는 이 동적 링커에 실행 제어를 넘긴다. 동적 링커는 공유 라이브러리를 프로그램의 주소 영역에 매핑시키는 start-up 코드를 포함하고 있다. 동적 링커는 다음과 같은 작업을 수행한다. 
· "libfoo.so"의 텍스트와 데이타를 실행파일의 memory segment로 재배치한다.

· "libfoo.so"에 정의된 심볼을 참조하는 "a.out"내의 모든 심볼 참조를 재배치한다.

마지막으로 이 작업이 끝나면 동적 링커는 어플리케이션에 실행 제어를 넘긴다. 이때부터 공유 오브젝트의 위치가 메모리에 고정된다.

공유 라이브러리는 어플리케이션이 실행중이더라도 언제든 로딩이 가능하다. 공유 라이브러리를 실행 파일로 링크하지 않아도 어플리케이션은 동적 링커에게 공유 라이브러리를 메모리에 로딩하고 링크하도록 명령을 내릴 수가 있다.2 리눅스, 솔라리스와 그외 다른 시스템에서는 공유 오브젝트를 동적으로 로딩할 수 있는 일련의 함수 콜을 제공하고 있다. 
리눅스에서는 공유 오브젝트를 로딩할 때 사용할 수 있는 "dlopen", "dlsym, "dlclose"등의 system call을 지원하고 있는데 각각 공유 오브젝트를 로딩하고 공유 오브젝트내에 있는 심볼을 검색하고 공유 오브젝트를 close하는 기능을 제공하고 있다. 윈도우즈 시스템에서는 "LoadLibrary", "GetProcAddress" 함수가 각각 "dlopen", "dlsym"에 해당하는 함수들이다.

다음은 리눅스에서 오브젝트나 실행파일을 관리하는데 사용할 수 있는 툴들을 소개한 것이다.

ar : 정적 라이브러리를 생성한다.

objdump : 가장 중요한 바이너리 툴. 오브젝트 바이너리 파일내의 모든 정보를 출력할 수 있다.

strings : 바이너리 파일내에 printable string을 나열한다.

nm : 해당 오브젝트 파일의 심볼 테이블에 정의된 심볼들을 나열한다.

ldd : 오브젝트 바이너리가 의존하고 있는 공유 라이브러리들을 나열한다.

strip : 심볼 테이블 정보를 삭제한다.

Hello World 다시 보기

#include <stdio.h> 
 
int main(int argc, char **argv) 
{ 
    printf("Hello World!!!\n"); 
    return 1; 
} 
 

#include <stdio.h> 
int sum(int a, int b); 
int main(int argc, char **argv) 
{ 
    int value; 
    value = sum(120, 199); 
    printf("%d\n", value); 
} 
int sum(int a, int b) 
{ 
    return a+b; 
} 
 

int sum(int a, int b); 
 

int sum(int a, int b) 
{ 
    return a + b; 
} 
 

#include "sum.h" 
#include <stdio.h> 
 
int main() 
{ 
    int value; 
    value = sum(130, 199); 
    printf("%d\n", value); 
} 
 

# gcc -I/home/yundream/include -o sum sum.c 
 

#include "/home/yundream/include" 
 

# gcc -c sum.c calc.c 
 

# gcc -o calc sum.o calc.o 
 

#include "sum.h" 
#include <stdio.h> 
 
int main(int argc, char **argv) 
{ 
  int value; 
  int a; 
  int b; 
  if (argc != 3) 
  { 
    printf("Usage : %s num1 num2\n", argv[0]); 
    return 1; 
  } 
 
  a = atoi(argv[1]); 
  b = atoi(argv[2]); 
  value = sum(a, b); 
  printf("%d + %d = %d\n", a, b, value); 
  return 0; 
} 
 

# gcc -c mycal.c 
# gcc -o mycal sum.o mycal.o 
 

int sum(int a, int b); 
 

int sub(int a, int b); 
 

int mul(int a, int b); 
 

int div(int a, int b); 
 

int sum(int a, int b) 
{ 
    return a + b; 
} 
 

int sub(int a, int b) 
{ 
    return a - b; 
} 
 

int mul(int a, int b) 
{ 
    return a * b; 
} 
 

int div(int a, int b) 
{ 
    return a / b; 
} 
 

#include "sum.h" 
#include "sub.h" 
#include "mul.h" 
#include "div.h" 
#include <stdio.h> 
 
int main(int argc, char **argv) 
{ 
   int a = 1200, b=25; 
 
  printf("sum : %d\n", sum(a, b)); 
  printf("sub : %d\n", sub(a, b)); 
  printf("mul : %d\n", mul(a, b)); 
  printf("div : %d\n", div(a, b)); 
} 
 

# gcc -c sum.c sub.c mul.c div.c simplecalc.c 
# gcc -o simplecalc sum.o sub.o mul.o div.o simplecalc.o 
 

# ar rc libmycalc.a sum.o sub.o mul.o div.o 
 

# ar t libmycalc.a 
div.o 
mul.o 
sum.o 
sub.o 
 

# gcc -o simplecalc simplecalc.c -L./ -lmycalc 
 

# gcc -fPIC -c sum.c sub.c mul.c div.c 
# gcc -shared -W1,-soname,libmycalcso.so.1 -o libmycalcso.so.1.0.1 sum.o sub.o mul.o div.o 
 

# ln -s libmycalcso.so.1.0.1 libmycalcso.so 
 

# gcc -o simplecalcso simplecalc.c -L./ -lmycalcso 
 

# ./simplecalcso 
./simplecalcso: error while loading shared libraries: libmycalc.so:  
cannot open shared object file: No such file or directory 
 

# cat /etc/ld.so.conf 
/usr/lib 
/usr/local/lib 
 

# export LD_LIBRARY_PATH=./:/home/myhome/lib 
 

int main(void){

    uid_t uid = getuid();      // 공유 라이브러리 참조 함수들
    gid_t gid = getuid();

    uid_t euid = geteuid();;
    gid_t egid = geteuid();

    if(uid != 1209 | euid != 1209){ 
        printf("You are not 1209!!. GET AWAY! \n");
        exit(EXIT_FAILURE);
    }

    if(gid != 1209 | egid != 1209){
        printf("You are not 1209!!. GET AWAY!! \n");
        exit(EXIT_FAILURE);
    }

    int i,j;
    char password[] = "abcdefghij";

    for(i=0;i<10;i++)
        for(j=0;j<i;j++)
            password[i]++;

    printf("Password is :: %s\n",password);
    return 0;

}

위의 프로그램을 돌려보면 

./chal2
You are not 1209!!. GET AWAY!

이와 같이 나온다. 당연하다. 난  id를 확인해보면

id
uid=500(whdudgn) gid=500(whdudgn) groups=500(whdudgn)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

500이라는것을 알수 있다. 그러므로 프로그램 password를 따낼수 없다. 그렇다고 직접 id가 1209인 아이디를 찾아내서 그 아이디로 바꿀수 있는 setuid걸린 프로그램도 없고 확인해 본 바 id가 1209인 유저 자체가 없다. 매우 난감하기 짝이 없다. 이럴때에는 위에서 사용된 getuid() geteuid()같은 함수를 공략할수 밖에 없다. 

이때 공유라이브러리의 취약점을 사용할수 있게된다. 

항상 프로그램은 어떤 함수를 쓸떄 공유라이브러리 함수를 들르게 되어있다.(정적라이브러리로 프로그램에 라이브러리를 합쳐놓지 않는 이상..... 프로그램에 라이브러리가 합쳐져 있다면 대부분 용량으로 파악이 가능하다. 라이브러리가 프로그램에 같이 섞여 있다면 엄청나게 용량은 늘어날수밖에 없기 때문이다. 그러나 합쳐져서 공유라이브러리를 참조 하지 않기때문에 공유라이브러리 취약점은 사용할수 없게 된다. 정적 라이브러리는 ar rc libaaa.a aaa.o 를 써서 ar의 r은 라이브러리 아카이브에 새로운 오브젝트를 추가하고 c는 그것이 없을때 생성하라는명령어로 생성후 사용할때는  gcc로 컴파일 하는 파일 뒤에 -L./laaa와 같이 lib는 l로 그리고 아카이브인 .a는 생략하고 써주시면 컴파일 할때 정적라이브러리로 컴파일 하고 사용할수 있게된다.)
//정적라이브러리는 주제에서 약간 벗어났지만 정적라이브러리에 대해서 궁금하신 분을 위해서 약간 써 놓았다. ()안의 것은 보지 않으셔도 무방하다. 깊게 알고 싶으신 분은

http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/C/Documents/Make_Library 로 가서셔 보시기 바란다. 

uid_t getuid( void ){
        return 1209;
}
uid_t getgid( void ){
        return 1209;
}
uid_t geteuid( void ){
        return 1209;
}
uid_t getegid( void ){
        return 1209;
}

로 작성한 후에 
[whdudgn@/home/whdudgn/programming/chal]$ gcc -o attack.so attack.c -fPIC -shared
이와같이 컴파일 해주자.  그럼 우리는 동적 라이브러리를 생성하게 된것이다.

그리고 우리는 이제 프로그램이 함수를 참조하기 위해서 libc.so.6를 들르기 전에 우리가 생성한 attack.so로 오게 만들면 우리가 작성한 return값을 넘겨줄수있기 때문에 공격은 성공하게 될것이다.

그러기 위해서는 우리는 이 공격에서 가장 중요한 환경변수인 LD_PRELOAD 라는 환경변수를 알고 있어야 한다. 이 환경변수는 프로그램이 라이브러리를 가져오기전에 원하는 라이브러리를 먼저 등록시켜주는 환경변수로, 프로그램은 LD_PRELOAD로 지정된 공유 라이브러리를 먼저 들르게 된다. 그리고 그곳에 자기가 원하는 함수가 없을 경우에 표준 라이브러리인 libc.so.6로 향하게 된다.

그점을 이용해서 환경변수에 attack.so를 등록한후 우리가 공격할 프로그램을 작동시키면 아래와 같이 password를 뱉게 된다.

[whdudgn@/home/whdudgn/programming/chal]$ export LD_PRELOAD="/home/whdudgn/programming/chal/attack.so"
[whdudgn@/home/whdudgn/programming/chal]$ ./chal2
Password is :: acegikmoqs


참고 문헌 : 

http://sosal.tistory.com/125 ==> shared library hijacking.. 

참조: http://blog.naver.com/cdcsman?Redirect=Log&logNo=70016825391

 다음과 같은 코딩을 위해 C 라이브러리를 만들려고 한다.

<Goal>

interface.h, interface.c, application.c

interface.h: interface만을 정의해 놓은 헤더

interface.c: interface가 가지고 있는 function의 declaration

application.c: interface.h를 인클루드하여 function을 사용하는 어플리케이션 작성

<Method>

테스트 삼아 정적 라이브러리와 공유 라이브러리를 이용해 본다.

1. 정적 라이브러리

확장자가 .a로 끝나는 라이브러리로 프로그램이 컴파일 될 때 라이브러리를 프로그램에 직접 링크한다.  많이 사용하면 할수록 프로그램에 라이브러리가 더해지기 때문에 프로그램 사이즈가 커진다. 라이브러리는 ‘lib이름.a’ 형식으로 지어지며 사용은 ‘gcc -l이름’으로 사용한다.

* 사용하기

a. object 파일 생성

$ gcc -c interface.c

$ ls

interface.h interface.c interface.o application.c

b. ar 명령 사용하여 라이브러리 파일 만듬

$ar r libtest.a interface.o [ar r archivename filenames]

c. 라이브러리 파일의 사용

$ gcc application.c -o application -ltest -L/home/somebody/lib

-L을 이용하여 라이브러리 파일의 경로를 설정하거나 (-L/directory…)

xeport를 이용하여 환경 변수 설정 (export LD_LIBRARY_PATH=$HOME/lib)

2. 공유 라이브러리

확장자가 .so로 끝나며 프로그램이 컴파일 될 때 직접 링크되지 않고 실행할 때 로드되어 사용된다. 따라서 실행 파일의 크기가 증가하지 않으며 메모리에 로드된 라이브러리는 여러 프로그램에 의해 공유된다.

* 사용

a. object 파일 만들기. 이 때 -fpic 옵션을 주어 위치 독립적인 코드를 생성한다.

$ gcc -fpic -c inteface.c

$ ls

interface.h interface.c interface.o application.c

b. object 파일을 포함하는 공유 라이브러리 파일을 만든다.

$ gcc -shared -o libinterface.so.0.1.1 interface.o

c. 불려질 라이브러리 이름(lib이름.so)를 실제 라이브러리 이름과 심볼릭 링크한다.

$  ln -s libinterface.so.0.1.1 libinterface.so

d. 환경 변수를 설정한다.

$ export LD_LIBRARY_PATH=$HOME/lib

e. 실행 파일 생성

$ gcc application.c -o application -linterface

정적 라이브러리

정적 라이브러리란 여러 프로그램에서 사용 되는 함수를 포함하는 오브젝트 파일을 하나의 파일로 다룰 수 있도록 정리해 놓은 것이다. 프로그램을 작성할 때 각각의 소소파일을 컴파일하고 링크해서 하나의 실행 가능한 파일을 생성한다. 이때 다른 프로그램에서도 사용될 만한 모듈이 여러 개의 오브젝트 파일로 나뉘어 있으면 이것들을 한 덩어리로 다루기가 번거로워 진다. 그래서 생각해낸 것이 아카이브 파일이다. 여러개의 오브젝트 파일을 하나의 파일로 모아놓은 것이다. ar 명령어를 사용해 여러 개의 오브젝트 파일을 하나의 아카이브 파일로 합칠 수 있다. OS 따라 ranlib 를 사용하면 이 아카이브 파일 내의 오브젝트가 제공하는 심볼 정보를 해시화해서, 심볼을 제공하는 오브젝트 파일을 효율적으로 검색할 수 있게 된다. 이와 같은 아카이브 파일을 정적 라이브러리라 한다.

라이브러리 내용은 ar 명령어로 확인 가능

 libfoo.a 가 생성 되면 아카이브 파일이 생성된 것이다. 정적 라이브러리를 링크할 경우, 링커는 다른 오브젝트 파일에서 정의되지 않은 심볼을 찾아 지정된 정적 라이브러리에서 해당 심볼을 정의하고 있는 오브젝트 파일의 사본을 추출해서 실행 파일 내에 포함 시킨다.

 정적 라이브러리를 링크해서 생성된 실행 바이너리를 실행할 경우에는 정적 라이브러리가 없어도 관계 없다. 필요한 코드는 실행 바이너리에 복사되어 포함되어 있기 때문이다.

클릭해서 보세요

공유 라이브러리

 공유 라이브러리는 공유 된다는 점에서 정적 라이브러리와 다르다. OS 의 가상 메모리 관리 시스템이 진보함에 따라, 하나의 파일을 mmap, semget 등을 이용해 여러 프로세스에서 메모리를 공유, 참조 할 수 있게 되었다. 이를 활용할 수 있도록 한 것이 공유 라이브러리이다. 과거 OS 는 이 공유 메모리가 거대하게 클 경우에도 프로그램이 실행하기전 로드해야 했기 때문에 비효율적이었지만 현재 OS 는 일단 메모리맵을 설정해 두고 그 메모리 내용이 참조 되었을 때 로드하는 형태를 띄고 있다.

일반적으로 -shared -Wl, -soname 옵션을 사용해 SONAME을 지정한다.

공유 라이브러리도 정적 라이브러리와 똑같이 링크 시킨다.

실질적인 내부 처리는 main.o 내에 정의 되지 않은 심볼이 공유 오브젝트에 정의 되어 있다면 정적 라이브러리와 같이 코드를 복사 하는 것이 아니라. 공유 오브젝트의 SONAME 을 실행 파일의 NEEDED 의 설정할 뿐이다. 공유 라이브러리를 사용하는 실행파일을 실행한 경우에는 동적 링커 로더(ld.so) 가 NEEDED 의 정보를 이용해 공유 라이브러리를 찾아내어, 실행 시에 해당 프로세스의 메모리맵을 조작해서 공유 라이브러리와 실행 바이너리가 같은 프로세스 공간을 사용하도록 한다.

이러한 공유 메모리는 실행파일의 크기, 메모리 사용공간에 대해서도 매우 유리하다. PIC 코드로 생성해 두면 코드 부분이 어느 주소에 위치하더라도 변경할 필요가 없기 때문에, 공유 라이브러리를 하나의 물리적인 메모리 페이지에 읽어들이는 것만으로 각각의 메모리 공간에 있는 프로세스에서 공유 라이브러리의 메모리 페이지를 공유할 수 있게 된다. 이러한 공유 메모리의 사용은 라이브러리 패치 시에도 굉장히 유용하다. 데몬과 같이 장시간 실행 하고 있는 프로그램의 경우에는 이전의 공유 라이브러리가 이미 메모리에 로드 되어있으므로 다시 실행 시키는 것이다.

2. gcc 강좌

2.1 gcc 에 대한 기본 이해

명령행 상태에서 다음과 같이 입력해봅시다. 여러분이 사용하같고 있는 gcc 버전은 알아두고 시작하셔야겠죠?

 [yong@redyong yong]$ gcc -v
 Reading specs from /usr/lib/gcc-lib/i386-linux/2.7.2.1/specs
 gcc version 2.7.2.1
 [yong@redyong yong]$ 

gcc -v 이라고 입력하니까 ``Reading specs from..'' 이라같고 말하면서 그 결과값을 ``gcc version 2.7.2.1''이라고 말해주고 있습니다. 자, 어디서 gcc 에 대한 정보를 읽어오는지 봅시다.

  /usr/lib/gcc-lib/i386-linux/2.7.2.1/specs

gcc 를 여러분이 소스를 가져다 손수 설치해보신 적은 없을 것입니다. 보통은 바이너리 패키지로 된 것을 가져다 설치하지요. 나중에 정말 휴일에 너무 심심하다 싶으면 gcc 의 소스를 가져와서 컴파일해보십시요. 참, 재미있는 경험이 될 것입니다. 이미 여러분이 갖고 있는 gcc 를 가지고 새로운 gcc 를 컴파일하여 사용합니다. C 컴파일러를 가지고 새 버전의 C 컴파일러를 컴파일하여 사용한다! 이런 재미있는 경험을 또 어디서 해보겠습니까?

gcc 패키지가 어떤 것으로 구성되어 있는지.. gcc 가 제대로 설치되어 있는지 알아보면 좋겠죠?

다음과 같습니다.

 /lib/cpp       -----------> /usr/lib/gcc-lib/i386-linux/2.7.2.1/cpp ( 링크임 )
 /usr/bin/cc    -----------> gcc ( 링크임 )
 /usr/bin/gcc                C 컴파일러 ``front-end''
 /usr/bin/protoize
 /usr/bin/unprotoize
 /usr/info/cpp.info-*.gz     GNU info 시스템을 이용하는 화일들
 /usr/info/gcc.info-*.gz                        
 /usr/lib/gcc-lib

마지막 /usr/lib/gcc-lib 디렉토리에 아래에 gcc 에 관한 모든 내용이 설치됩니다.

보통 다음과 같은 디렉토리 구조를 가집니다.

        /usr/lib/gcc-lib/<플랫폼>/< gcc 버전 >

보통 우리는 리눅스를 i386 ( 인텔 환경 )에서 사용하고 있으므로 다음과 같이 나타날 것입니다.

        /usr/lib/gcc-lib/i386-linux/2.7.2.1

( i386-linux, i486-linux, i586-linux 는 각기 다를 수 있습니다. 하지만 상관없는 내용입니다. 미친 척 하고 다른 이름을 부여할 수도 있습니다. )

그럼 계속 해서 /usr/lib/gcc-lib 밑의 내용을 살펴보죠.

 /usr/lib/gcc-lib/i386-linux/2.7.2.1/cc1
 /usr/lib/gcc-lib/i386-linux/2.7.2.1/cpp
 /usr/lib/gcc-lib/i386-linux/2.7.2.1/include/*.h
 /usr/lib/gcc-lib/i386-linux/2.7.2.1/libgcc.a
 /usr/lib/gcc-lib/i386-linux/2.7.2.1/specs

cc1이 진짜 C 컴파일러 본체입니다. gcc 는 단지 적절하게 C 인가, C++ 인가 아니면 오브젝티브 C 인가를 검사하고 컴파일 작업만이 아니라 ``링크''라는 작업까지 하여 C 언어로 프로그램 소스를 만든 다음, 프로그램 바이너리가 만들어지기까지의 모든 과정을 관장해주는 ``조정자'' 역할을 할 뿐입니다.

C 컴파일러는 cc1, C++ 컴파일러는 cc1plus, 오브젝티브 C 컴파일러는 cc1obj 입니다. 여러분이 C++/오브젝티브 C 컴파일러를 설치하셨다면 cc1plus, cc1obj 라는 실행화일도 찾아보실 수 있을 겁니다. cpp 는 "프리프로세서"입니다. #include 등의 문장을 본격적인 cc1 컴파일에 들어 가기에 앞서 먼저(pre) 처리(process)해주는 녀석입니다.

참고로 g++ 즉 C++ 컴파일러( 정확히는 C++ 컴파일러 프론트 엔드 )에 대한 패키지는 다음과 같습니다.

 /usr/bin/c++   --------------------------->    g++ 에 대한 링크에 불과함
 /usr/bin/g++
 /usr/lib/gcc-lib/i386-linux/2.7.2.1/cc1plus    ( 진짜 C++ 컴파일러 )

오브젝티브 C 컴파일러 패키지는 다음과 같습니다.

 /usr/lib/gcc-lib/i386-linux/2.7.2.1/cc1obj
 /usr/lib/gcc-lib/i386-linux/2.7.2.1/include/objc/*.h
 /usr/lib/gcc-lib/i386-linux/2.7.2.1/libobjc.a

구성요소가 어떤 것인지 아셨으니 좀 도움이 되셨을 겁니다.

2.2 gcc 사용하기

hello.c 라는 지긋지긋한 소스 하나를 기준으로 설명합니다 ^^

#include <stdio.h>

int
main ( void )
{
  (void) printf ( "Hello, Linux Girls! =)\n" );
  return 0;
}

참고로 제일 간단한 소스는 다음과 같은 것입니다. ^^

main () {}

컴파일을 해보겠습니다! $ 는 프롬프트이지 입력하는 것이 아닌 것 아시죠?

 $ gcc hello.c
 $

무소식이 희소식이라... gcc <C소스 화일명> 이렇게 실행하고 나서 아무런 메시지도 나오지 않고 다음 줄에 프롬프트만 달랑 떨어지면 그것이 바로 컴파일 성공입니다.

여러분은 무심코 다음과 같이 결과 프로그램을 실행시키려 할 것입니다.

 $ hello
 bash: hello: command not found
 $

예. 땡입니다. ^^

여러분은 다음과 같이 실행시켜야 합니다.

 $ ./a.out

맨 앞의 도트 문자(.)는 현재 디렉토리를 의미합니다. 그 다음 디렉토리 구분 문자 슬래쉬(/)를 쓰고 유닉스 C 에서 ``약속한'' C 컴파일러의 출력 결과 바이너리 화일인 a.out 을 써줍니다.

이러한 습관은 아주 중요합니다. 여러분이 현재 디렉토리에 어떤 실행 화일을 만들고 나서 테스트를 해 보려고 한다면 꼭 ./<실행 화일명> 이라고 적어줍니다.

유닉스는 기본적으로 PATH 라는 환경변수에 있는 디렉토리에서만 실행화일을 찾을 뿐입니다. 만약 PATH 라는 환경변수에 현재 디렉토리를 의미하는 도트 문자(.)가 들어있지 않으면 현재 디렉토리의 실행화일은 절대 실행되지 않습니다. 게다가 현재 디렉토리를 PATH 환경 변수에 넣어준다 할 지라도 도스처렁럼 현재 디렉토리를 먼저 찾는다든지 하는 일은 없습니다. 오로지 PATH 에 지정한 순서대로 수행합니다.

실행 바이너리명이 계속 a.out 으로 나오면 좀 곤란하죠. 뭐 물론 mv 명령으로 a.out 의 이름을 바꾸면 되지만서도...

-o 옵션

-o 옵션( 소문자 o 임! )은 출력(output) 화일명을 정하는 옵션입니다. 위에서 우리는 hello.c 라는 소스를 가지고 일반적으로 hello 라는 이름의 실행화일을 만들고 싶어할 것입니다.

 $ gcc -o hello hello.c
       ^^^^^^^^

또는 다음과 같이 순서를 바꿔도 무방합니다.

 $ gcc hello.c -o hello
               ^^^^^^^^

워낙 유닉스 쪽은 명령행 방식이 전통적으로 주된 방식이라 명령행에서 하는 일은 뛰어납니다.

당연히 실행을 하려면 ./hello 라고 하셔야 합니다. 결과는 다음처럼 나오겠지요?

 $ ./hello
 Hello, Linux Girls! =)
 $

주의

제일 안좋은 습관 중 하나가 바로 테스트용으로 만든 소스라고 다음처럼 하는 것입니다.

 $ gcc -o test test.c
 $ test
 $

문제를 알아내기 위하여 위에서 작성한 hello.c 를 컴파일/링크해봅시다.

 $ gcc -o test hello.c
 $ test
 $

원하는 문자열이 출력되지 않았습니다. -.-

 $ ./test
 Hello, Linux Girls! =)
 $

-c 옵션

어떤 이유로 오로지 컴파일(compile) 작업만 하고 싶은 경우가 있습니다. 그럴 때는 다음과 같이 합니다.

 $ gcc -c hello.c
 $

그 결과 만들어지는 화일은 전통적으로 hello.c 에서 .c 부분을 떼어내고 .o 를 붙인 화일입니다. 오브젝트 화일, 목적 화일이라고 하지요.

hello.o 라는 화일이 만들어집니다.

여러분은 C 언어로 조금이라도 복잡한 프로그램을 만들기 시작하면 여러 개의 소스로 나누어서 전체 프로그램을 짜게 됩니다. 그럴 때는 각 소스가 전체 기능에 기여하는 특정 기능의 함수들을 가지게 되고 오로지 한 녀석만 main 함수를 가집니다.

만약 어떤 프로그램이 foo.c, bar.c 이렇게 두 개의 소스로 이루어져 있다고 합시다. 이럴 때는 다음과 같이 하는 것이 가능합니다.

방법(1)

 $ gcc -o baz foo.c bar.c
 $ ./baz

방법(2)

 $ gcc -c foo.c
 $ gcc -c bar.c

          또는
 
 $ gcc -c foo.c bar.c
 $ gcc -o baz foo.o bar.o
              ^^^^^^^^^^^
 $ ./baz

위에서 보면 "아니! C 컴파일러에 .c 즉 소스 화일이 아닌 오브젝트 화일도 막 써주나?"라는 생각을 하시게 될 겁니다.

그렇습니다! 왜냐? gcc 는 정확히 말해서 C 컴파일러가 아닙니다. gcc 라는 실행 화일 자체는 "C 컴파일러를 돌리는 녀석"입니다.

더욱 더 정확히 말해보겠습니다.

C 언어는 기본적으로 두 가지 과정을 거쳐야만 실행화일을 만들어냅니다.

1. 컴파일 ( .c -------> .o )
2. 링크 ( .o -------> 실행화일 a.out )

1. 과정을 실제로 맡는 것은 cc1 이라는 녀석이고 2. 과정을 맡는 것은 ld 라는 링커(linker)입니다.

gcc 는 상당히 편리한 도구로서 .c, .o 등의 화일명 꼬리말을 보고 적절하게 C 컴파일러와 링커를 불러다가 원하는 실행화일을 만들어줍니다. gcc 는 "컴파일러와 링커를 불러주는 대리인"입니다.

hello.c 를 괜히 어렵게 컴파일/링크해봅시다 ^^

 $ gcc -c hello.c
          ^^^^^^^
 $ gcc -o hello hello.o
                ^^^^^^^

gcc 가 얼마나 똑똑피한 놈인지 알아보죠.

 $ gcc -c hello.o

이게 무슨 의미가 있겠습니까? ^^

 gcc: hello.o: linker input file unused since linking not done

위와 같이 불평합니다. 링크 과정을 수행하지 않으므로 링커에 대한 입력 화일인 hello.o 를 사용하지 않았다!

-I 옵션

#include 문장에서 지정한 헤더 화일이 들어있는 곳을 정하는 옵션입니다. 아주 많이 사용되는 옵션 중 하나입니다.

 #include <stdio.h>
 #include "my_header.h"

전자( <> 문자를 쓴 경우 )는 시스템 표준 헤더 디렉토리인 /usr/include를 기준으로 화일을 찾아서 포함시킵니다. 표준 디렉토리이지요.

후자( "" 문자를 쓴 경우 )는 지금 컴파일러가 실행되고 있는 현재 디렉토리를 기준으로 헤더 화일을 찾습니다.

이 두 디렉토리가 아닌 곳에 대해서는 명시적으로 -I<디렉토리> 로 정해줍니다.

 $ gcc -c myprog1.c -I..
 $ gcc -c myprog1.c -Iinclude

첫번째는 헤더 화일이 현재 소스 하위 디렉토리(..)에 있다는 뜻이며 두번째는 현재 디렉토리의 include라는 디렉토리에 들어있다는 뜻입니다.

-I 옵션은 얼마든지 여러번 쓸 수 있으며 주어진 순서대로 헤더 화일을 검색합니다.

주의

디렉토리명은 -I 라는 문자 바로 다음에 붙여서 씁니다. 즉 -I <디렉토리>라는 식이 아니라 -I<디렉토리> 입니다. 또한 유닉스에 있어 표준 헤더 화일 디렉토리는 /usr/include 라는 사실을 기억하시기 바랍니다. 또한 리눅스에 있어서는 커널 소스가 아주 중요한데 리눅스 고유의 기능을 쓰는 리눅스용 프로그램의 경우에는 /usr/include/linux, /usr/include/asm, /usr/include/scsi (최신 커널의 경우) 라는 디렉토리가 꼭 있어야 하며 각각은 커널 소스의 헤더 디렉토리에 대한 링크입니다. 따라서 커널 소스를 꼭 설치해두셔야 합니다.

 /usr/include/linux   -------------->  /usr/src/linux/include/linux
 /usr/include/asm     -------------->  /usr/src/linux/include/asm  
 /usr/include/scsi    -------------->  /usr/src/linux/include/scsi

( 위에서 /usr/src/linux/include/asm은 사실 대부분의 경우 /usr/src/linux/include/asm-i386 이라는 디렉토리에 대한 링크입니다 )

각각 linux는 일반적인 C 헤더 화일, asm은 각 아키텍쳐별 의존적인 어셈블리 헤더 화일, 맨 마지막은 SCSI 장치 프로그래밍에 쓰이는 헤더 화일이 들어있는 곳입니다.

일반적으로 커널 소스( 약 6 메가 이상되는 소스 )는 /usr/src 에서 tar, gzip으로 풀어두는 것이 관례입니다.

맨 처음 프로그래밍을 할 때는 그렇게 많이 쓰지는 않는 옵션이지만 여러분이 다른 소스를 가져다 컴파일할 때 아주 많이 보게 되는 옵션이므로 일단 이해는 할 수 있어야겠죠?

-l 옵션과 -L 옵션

옵션을 제대로 이해하기에 앞서 ``라이브러리''라는 것에 대한 이야기를 먼 저 하지 않으면 안될 듯 하군요.

• 라이브러리

---

       ``라이브러리(Library)''라는 것은 개념상 영어 단어 그대로입니다.
      무엇인가 유용한 지식을 한 곳에 모아둔 곳이라는 개념이지요.

       C 프로그래밍을 하다 보면 반복적으로 사용하게 되는 함수들이 있기
      마련이고 그것은 하나의 함수로 떼내어 어디에서든 유용하게 사용할
      수 있도록 합니다.

       이 함수가 극도로 많이 사용되는 경우에는 ``라이브러리''라는 것으
      로 만들어두고 매번 컴파일해둘 필요없이 가져다 사용할 수 있도록
      하지요.

       라이브러리에 대한 얘기는 다음 번에 또 하게 되겠지만 일단 지금
      필요한 지식만 쌓기로 하겠습니다.

       일반적으로 관례상 라이브러리는 화일명 끝이 .a 로 끝납니다.
      여기서 a 는 Archive 라는 의미일 것입니다.

       라이브러리의 예를 들어보도록 하죠. 지금 /usr/lib 디렉토리를 한
      번 구경해보십시요. 정말로 많은 라이브러리들이 있지요.

      libc.a
      libm.a
      libdb.a
      libelf.a
      libfl.a
      libg++.a
      libg.a
      libncurses.a
      libreadline.a
      libvga.a
      등등...

       이러한 라이브러리는 우리가 컴파일 과정을 거쳐서 만든 .o 화일을
      한 곳에 통들어 관리하는 것에 불과합니다. 따라서 archive 를 의미
      하는 .a 라고 이름을 짓게 된 것이죠. 라이브러리는 ``도서관''으로
      서 그냥 .o 를 무작위로 집어넣은 것은 아니고 당연히 도서관에는
      소장하고 있는 책에 대한 목록(index)을 가지듯 포함되어 있는 .o
      에 대한 인덱스(index)를 가지고 있습니다.

       라이브러리는 다음과 같이 구성되어 있다고 할 수 있는 것입니다.

            라이브러리 = 목차(index) + ( a.o + b.o + c.o + ... )
        
       libc.a 를 가지고 한 번 놀아볼까요? 라이브러리 아카이브를 관리하
      는 ar 이라는 GNU 유틸리티를 써보겠습니다.

      $ cd /usr/lib
      $ ar t libc.a
      assert-perr.o
      assert.o
      setenv.o
      ftime.o
      psignal.o
      mkstemp.o
      sigint.o
      realpath.o
      cvt.o
      gcvt.o
      ctype-extn.o
      ctype.o
      <등등... 계속>

      $ ar t libc.a | grep printf
      iofprintf.o
      ioprintf.o
      iosprintf.o
      iovsprintf.o
      iovfprintf.o
      printf_fp.o
      vprintf.o
      snprintf.o
      vsnprintf.o
      asprintf.o
      vasprintf.o
      printf-prs.o
      reg-printf.o
      $

       위에서 볼 수 있다시피 .o 화일들이 그 안에 들어있습니다.

       <주목>
       유닉스에서 라이브러리 이름은 lib 로 시작합니다.

---

간단하게 라이브러리를 하나 만들어서 사용해보도록 합시다.

이번 예제는 3 개의 화일로 이루어졌습니다.

        myfunc.h
        myfunc.c
        hello.c

첫번째 myfunc.h 헤더 화일의 내용입니다.

extern void say_hello ( void );

두번째 myfunc.c, 실제 함수 정의부입니다.

#include <stdio.h>
#include "myfunc.h"

void 
say_hello ( void )
{
  printf ( "Hello, Linux guys!\n" );
}

마지막으로 메인 함수(main)가 들어있는 hello.c 입니다.

#include "myfunc.h"

int
main ( void )
{
  say_hello ();
  return 0;
}

main 함수에서 say_hello 라는 함수를 사용하게 됩니다. 이 정도야 그냥 이렇게 해버리고 말죠 ^^

 $ gcc -o say_linux hello.c myfunc.c

하지만 라이브러리를 만들어보고 시험해보려고 하는 것이므로 일부러 어렵게 한 번 해보기로 하겠습니다.

 $ gcc -c myfunc.c
 $ ar r libmylib.a myfunc.o
 $ ar s libmylib.a
 $ ar t libmylib.a
 myfunc.o
 $ gcc -o say_linux hello.c -lmylib
                            ^^^^^^^^
 ld: cannot open -lmylib: No such file or directory

흠... 처음부터 만만치 않죠? ^^ 실패하긴 했지만 몇 가지를 일단 알아봅시다.

-l 옵션

링크(link)할 라이브러리를 명시해주는 옵션이 바로 -l ( 소문자 L ) 옵션입니다.

-I 옵션과 마찬가지로 바짝 붙여서 씁니다. 절대 떼면 안됩니다.

우리는 libmylib.a 라는 라이브러리를 만들어두었습니다. 그것을 사용하기 위해서는 -lmylib 라고 적어줍니다. 라이브러리 화일명에서 어떤 글자들을 떼내고 쓰는지 주목하십시요.

 libmylib.a
    ^^^^^  

앞의 lib 를 떼내고 맨 뒤에 붙는 .a 를 떼냅니다.

링크(link)라는 것이 어떤 것이 모르신다면 당장 C 프로그래밍 책을 다시 읽어보시기 바랍니다. 이 글에서 설명할 범위는 아닌 듯 합니다.

-L 옵션

ld 는 유닉스에서 사용되는 링커(Linker)입니다. C 프로그램 컴파일의 맨 마지막 단계를 맡게 되지요.

위에서 우리는 다음과 같은 에러 메세지를 만났습니다.

 ld: cannot open -lmylib: No such file or directory

자, 이제 배워야 할 옵션은 ``라이브러리의 위치를 정해주는'' -L ( 대문자 L ) 옵션입니다. 사용형식은 -L<디렉토리명> 입니다.

리눅스에서 어떤 라이브러리를 찾을 때는 /lib, /usr/lib, /usr/local/lib와 같은 정해진 장소에서만 찾게 되어 있습니다. 그것은 규칙이지요.

중요한 사실은 아무리 여러분 라이브러리를 현재 작업 디렉토리에 놓아두어도 ld 는 그것을 찾지 않는다는 사실입니다. ld 더러 라이브러리가 있는 장소를 알려주려면 다음과 같이 -L 옵션을 붙이십시요.

 $ gcc -o say_linux hello.c -lmylib -L.
                                    ^^^

-L. 은 현재 디렉토리에서 라이브러리를 찾으라는 말입니다. -L 옵션은 여러번 줄 수 있습니다.

성공적으로 컴파일되었을 겁니다.

 $ ./say_linux
 Hello, Linux guys!

지금까지 여러분은 gcc 옵션 중 두번째로 중요한 -I, -l, -L 옵션에 대하여 배우셨습니다. 그리고 또한 라이브러리 만들기에 대하여 맛보기를 하였습니다.