GNU 프로젝트의 구현물에 대해서는 GNU 링커 문서를 참고하십시오.
링크 과정을 간단히 나타낸 그림. 목적 파일과 정적 라이브러리가 새로운 라이브러리나 실행 파일로 병합되고 있다.
**링커**(linker) 또는 **링크 에디터**(link editor)는 컴퓨터 과학에서 컴파일러가 만들어낸 하나 이상의 목적 파일을 가져와 이를 단일 실행 프로그램으로 병합하는 프로그램이다.

OS/360과 같은 IBM 메인프레임 환경에서 이 프로그램은 링키지 에디터(*linkage editor*)로 알려져 있다.

유닉스 계열 운영 체제에서 **로더**를 링커의 동의어로 사용된다. 이 밖에 다른 용어들도 사용되었다. 이를테면 SINTRAN III에서는 링커가 수행한 프로세스를 **로딩**(loading→실행 코드를 파일로 로드)이라 하였다. 이러한 용도가 컴파일 타임 프로세스와 실행 시간 프로세스의 구별을 모호하게 만들었기 때문에, 이 문서는 전자의 의미로는 링크(linking)로, 후자의 의미로는 로드(loading)로 언급할 것이다. 그러나 일부 운영 체제에서 동일 프로그램은 프로그램을 링크하고 로드하는 작업을 모두 수행한다.(동적 링크를 참조할 것)

개요
--

컴퓨터 프로그램들은 일반적으로 여러 부분의 모듈로 이루어진다. 이 모든 부분/모듈들은 하나의 목적 파일 안에 포함될 필요는 없으며, 이런 경우 기호(symbol)을 다른 모듈 안의 주소로 이용해서 서로 참조한다. 그리고 이 기호는 실행을 위해 링크 될 때 메모리 주소로 맵핑된다. 일반적으로 모든 목적 파일은 3가지 종류의 기호를 포함할 수 있다:

* 정의된 "외부" 기호 (defined "external" symbols), 혹은 그냥 "공개(public)" 또는 "진입(entry)" 기호. 다른 모듈이 호출하는 것을 허용한다.
* 정의되지 않은 "외부" 기호 (undefined "external" symbols). 이 기호가 정의된 다른 모듈을 참조한다.
* 지역 기호 (local symbol). - 재배치를 위해 목적 파일 안에서 내부적으로 사용한다.

대부분의 컴파일러에서 각각의 목적 파일은 하나의 입력 소스 코드 파일의 컴파일 결과이다. 한 프로그램이 여러 개의 목적 파일로 구성될 때 링커는 이 파일들을 하나의 통합된 실행 가능한 프로그램으로 합치고 이때 생겨나는 기호들을 해결한다(resolve).

링커는 *라이브러리* 또는 *런타임 라이브러리*라고 하는 모음에서 오브젝트들을 취할 수 있다. 대부분의 링커들은 전체 라이브러리를 출력 파일에 포함시키지 않는다. 대신, 다른 오브젝트 파일 혹은 라이브러리가 참조하는 파일들만을 포함한다. 그래서 라이브러리 링킹은 반복적인 과정일 수 있는데, 어떤 참조된 모듈이 다른 추가적인 모듈을 필요로 하는 등의 경우가 있기 때문이다. 라이브러리는 다양한 목적으로 존재하는데, 하나 이상의 시스템 라이브러리는 보통 자동으로 링크된다.

링커는 또한 프로그램의 주소 공간 안의 오브젝트들을 배열하는 일도 책임진다. 이 일은 코드를 *재배치* 할 수도 있는데, 이 과정에서 특정한 베이스 주소를 다른 베이스로 가정한다. 컴파일러는 어떤 오브젝트가 어디에 배치될지 거의 모르기 때문에, 보통 0과 같은 고정된 베이스 주소를 가정한다. 기계 코드를 재배치하는 일은 절대 주소로 점프하는 코드(jump)와 로드(load), 스토어(store)의 목적 주소를 바꾸기도 한다.

링커가 만드는 최종 실행 파일은 (실행 직전에) 메모리에 최종적으로 올라가기 전에 또 다른 재배치 과정을 필요로 하기도 한다. 이 과정은 보통 가상 메모리를 지원하는 하드웨어에서는 생략된다. 모든 프로그램이 그들만의 주소 공간에 배치되고 따라서 모든 프로그램이 같은 베이스 주소를 로드해도 충돌이 나지 않기 때문이다. 이 과정은 위치 독립 실행 파일일 때에도 생략될 수 있다.

SINTRAN III와 같은 몇몇 유닉스 시스템에서는, 링커가 수행하는 이런 (목적 파일을 하나의 프로그램으로 묶는) 과정을 로딩 이라고 불렀다. 또한 어떤 운영체제에서는 같은 프로그램이 프로그램을 링크하고 로딩하는 일 모두를 다루기도 한다.

동적 링크
-----

수많은 운영 체제 환경은 동적 링크를 허용하며 프로그램이 실행될 때까지 정의되지 않은 일부 기호들을 해결하는 일을 나중으로 미룬다. 다시 말해, 실행 코드에는 정의된 기호, 또 이들의 정의들을 제공하는 오브젝트나 라이브러리의 목록이 여전히 포함되어 있다. 프로그램을 로드하면 이러한 오브젝트나 라이브러리도 로드할 것이며 마지막 링크를 수행한다. 동적 링크는 링커가 필요 없다.

이러한 접근에는 두 가지 이점이 있다:

* 자주 쓰이는 라이브러리 (이를테면 표준 시스템 라이브러리)는 한 위치에만 저장되어 있으며 여러 단일 라이브러리로 중복될 필요는 없다.
* 라이브러리 함수의 오류가 라이브러리 파일의 교체로 수정된다면 모든 프로그램은 다시 시작할 때 동적으로 이러한 수정에 영향을 받을 수 있다.

단점은 다음과 같다:

* 윈도 플랫폼에서 비호환 업데이트 DLL로 불리는 DLL 지옥이 이전 DLL의 행위에 의존했던 실행 파일의 실행을 저지할 수 있다.
* 라이브러리를 함께 사용하는 프로그램과 라이브러리 모두 검증이 필요할 수 있다. (정확성, 문서 요구 사항, 성능 등)

참고 문헌
-----

1. ↑  *BRF-LINKER User Manual*. ND-60.196.01. 08/84.

* David William Barron, *Assemblers and Loaders*. 1972, Elsevier.
* C. W. Fraser and D. R. Hanson, *A Machine Independent Linker*. Software-Practice and Experience 12, 4 (April 1982).
* IBM Corporation, *Operating System 360, Linkage Editor, Program Logic Manual*, 1967
* Douglas W. Jones, *Assembly Language as Object Code*. Software-Practice and Experience 13, 8 (August 1983)
* John R. Levine: *Linkers and Loaders*, Morgan-Kauffman, ISBN 1-55860-496-0.
* Leon Presser, John R. White: *Linkers and Loaders*. ACM Computing Surveys, Volume 4, Number 3, September 1972, pp. 149–167
* Norman Ramsey, *Relocating Machine Instructions by Currying*. (1996) [깨진 링크(과거 내용 찾기)]
* David Salomon, *Assemblers and Loaders*. 1993