Quick Flow
text
source file
-> preprocess / compile
-> object file
-> link with other objects and libraries
-> executable or library
-> operating-system loader
-> process starts문법·타입 오류는 주로 compile 단계, 정의를 찾지 못하는 symbol 오류는 link 단계, 필요한 동적 라이브러리나 진입 조건을 찾지 못하는 문제는 load·start 단계에서 발생합니다.
CPU·메모리·운영체제까지 포함한 실행 전체가 아니라, source에서 process 시작 직전까지의 build와 loading 경계를 좁혀 보는 카드입니다.
단계별 입력
compile은 각 translation unit의 소스를 분석해 목적 코드와 symbol 정보를 만듭니다. C와 C++에서는 전처리 결과와 헤더 선언이 이 단계의 입력에 포함됩니다. 소스 파일 하나가 독립적으로 컴파일되어도 프로그램 전체 정의가 모두 연결되었다는 뜻은 아닙니다.
link는 여러 object와 library의 symbol 참조를 해결하고 실행 파일 또는 library를 만듭니다. 선언은 보였지만 정의가 없거나 같은 정의가 충돌하면 linker 오류가 납니다.
load는 운영체제가 실행 결과물을 프로세스 주소 공간에 배치하고 필요한 동적 라이브러리를 연결하는 단계입니다. 성공한 build 결과도 대상 machine에 runtime이나 library가 없으면 시작하지 못할 수 있습니다.
오류 위치 찾기
| 증상 | 먼저 볼 단계 |
|---|---|
| syntax error, type mismatch | compile |
| unresolved external symbol | link |
| duplicate symbol | link와 정의 규칙 |
| DLL 또는 shared library를 찾지 못함 | load |
| 실행 뒤 access violation | runtime |
Build는 이 여러 단계와 코드 생성, asset 처리, packaging을 묶는 더 넓은 작업 이름입니다. 따라서 “컴파일은 성공했는데 빌드는 실패했다”는 표현은 충분히 가능합니다.
자주 틀리는 점
- header를 include한 사실이 함수 정의를 자동으로 제공하지는 않습니다.
- debug와 release는 최적화, runtime, symbol 조건이 달라 같은 문제를 다르게 드러낼 수 있습니다.
- 실행 파일이 만들어졌다고 대상 환경에서 필요한 동적 의존성이 모두 있는 것은 아닙니다.
- linker 오류를 source 문법 수정만으로 해결하려 하지 말고 symbol 이름과 library 연결을 확인합니다.
참고 링크
2 sources