<비공식 번역>awesome-c Beginner 번역 : 8. Object file dependency calculation

현재위치

1. Configuration

2. Standard directory dectection

3. Source file dependency calculation

4. Header file location

5. Header precompileation

6. Preprocessing

7. Compliation and assembly

8. Object file dependency calculation

9. Linking

10. Installation

11. Resource linking

12. Package generation

13. Dynamic linking

<주의!!>

nethack4.org의 'Building C Projects'의 공식적인 번역이 아니며 검수를 받은 것 역시 아닙니다!!

---

8: Object file dependency calculation (8: 오브젝트 파일 종속성 계산)

우리가 오브젝트 파일을 가지고 있다면, 다음 단계는 실행할 수 있는 형태가 되도록 만들어야합니다. 오브젝트 파일의 소스 둘이 있다고 합시다; 하나는 내장 C 소스 파일이고 다른 하나는 시스템 라이브러리입니다. (시스템 라이브러리는 오브젝트 파일에 직접 적재될 수 있습니다; 더 일반적으로, 오브젝트 파일의 라이브러리들을 확장자 .lib 또는 .a 로 묶습니다. 이는 여러가지 오브젝트 파일을 포함하는 단순한 아카이브입니다. 보통 몇가지 여분의 메타데이터와 함께 링커가 더 빠르게 연관된 오브젝트 파일을 알아낼 수 있도록 합니다. 리눅스와 유닉스를 기초로한 Mac OS X에서 여러분은 커맨더 ar x 으로 라이브러리를 언팩하고 직접 내부의 오브젝트 파일을 직접 볼 수 있습니다.)

실행파일을 생성하기 위해, 우리는 의존성이 충족되지 않은 오브젝트 파일과 라이브러리의 목록이 필요합니다; 오브젝트 파일에서 어떤 정의되지 않은 심볼은 (우리의 Hello World 오브젝트 파일의 stdout과 같은) 다른 오르젝트 파일 중 하나에 의해 정의될 필요가 있습니다. 우리는 또한 프로그램의 "시작점, 엔트리 포인트(entry point)"이 필요하고, 그 곳은 실행할 때 시작하는 지점입니다. (이 방법은 엔트리 포인트를 표준 라이브러리의 어딘가에 만드는 방법이며, 오브젝트 파일의 일반적인 목적은 엔트리 포인트를 제공하는 것입니다; 그리고 오브젝트 파일은 main을 호출하고 호출과 정리하기전에 초기화를 수행합니다.)

따라서, 빌드 수행의 필요한 것은 그러한 리스트를 작성하는 것입니다. 이것은 보통 프로그래머의 몫으로 남겨집니다, 그리고 제 생각엔, 프로그래머가 이 일을 하는 것은 최악의 아이디어입니다. 인간이 하는 평소의 일처럼, 오류를 만들기 일쑤입니다. 일반적으로 사람에게 남겨진 다른것들과 달리, 이것 또한 시간이 어느정도 걸립니다. 당신이 프로젝트에 새로운 파일을 추가할 때마다, 여러분은 실행파일 중 하나 이상의 소스를 추가할 필요가 있습니다 (또는 라이브러리, 여러분 빌드의 일부분으로 라이브러리를 구축하는 경우).

따라서 이는 자동화를 위한 훌륭한 후보이고, 이 개념은 매우 간단합니다: 우리는 실행가능한 main 함수를 가지고 있고, 우리는 재귀적으로 이미 빌드의 부분으로 오브젝트 파일에 정의되어 있지 않은 심볼이 정의된 오브젝트 파일이나 라이브라리를 만드는데 필요한 파일들을 찾습니다. Hello World 프로그램의 경우, aimake는 심볼 테이블을 확인하여 우리 메인 프로그램을 시작할 것입니다. stdout과 fwrite의 정의의 필요를 발견하고, 이어서 표준 라이브러리를 찾고, 이들을 수행할 것입니다.

한가지 잠재적인 문제점은 여러파일에서 동일한 이름으로 정의된 심볼이 있을 경우입니다, 그러나 aimake는 작업에서 인공지능을 사용해 올바른 프로그램을 위해 파일에서 그 일을 훌륭히 수행합니다. 그러나 여기엔 또다른 문제점이 있습니다: 입력 프로그램에 미묘한 오류가 있을 경우(라이브러리의 공식API를 사용하는 것 보다, 프로젝트에서 다른 위치에 정의된 라이브러리의 세부구현에 대한 연결같은), aimake는 보통 그러한 작업에 대한 해결책을 어떻게든 찾습니다. (예를들어 그 라이브러리의 관련된 오브젝트 파일을 직접적으로 연결), 비록 그것이 우리가 원한 것이 아닐지라도 말입니다. 현재, 저는 적어도 매달에 한번씩은 수동으로 심볼테이블을 점검하여 이러한 일이 일어나지 않도록 확인하지만 이로는 불만족스럽습니다. 이상적으로는, aimake가 말하는 특정 파일을 분리해서 보관하는 방법이 있습니다. (또는 자동으로 추론하는 방법이 있습니다.); 현재 이를 수행하는 기본적인 방법은 각각의 링크 오류를 강제로 동일한 이름으로 심볼을 정의하는 것입니다. 그러나 이마저도 만족스러운 방법은 아닙니다.

다양한 오브젝트 파일에 정의된(또는 참조하지만 정의하지 않은) 실제 심볼을 발견하는 위해서, 우리는 그것의 심볼 테이블 헤더를 봐야할 필요가 있습니다. 우리는 이를 위해서 objdump와 같은 프로그램을 사용할 수 있습니다만 이는 시스템 별로 다릅니다; 더 대중적으로 사용되는 프로그램, nm은 더 구체적으로 심볼 테이블을 다룹니다. 다시 말하면, 우리는 변화하는 출력 포멧에 대처해야 하고, 특이하고 이상한 문제를 건너야 합니다: POSIX는 nm에 대한 표준 출력 포멧을 정의하지만 여러분이 그 포멧을 얻는 방법은 어디까지나 nm의 구현에따라 다릅니다, 특히 표준으로는 유용하지 않습니다. 한편, nm의 기본 출력 포멧이 직접적으로 매칭하는 것은 문제되지 않습니다.

출처1 : https://github.com/aleksandar-todorovic/awesome-c

출처2 : http://nethack4.org/blog/building-c.html