링크는 라이브러리를 참조하는 오브젝트 파일보다 먼저 라이브러리를 사용합니다.
- 프로그램을 컴파일하고 GCC 툴체인과 연결하려고합니다.
- 연계는 필요한 모든 라이브러리 및 라이브러리 검색 경로를 지정합니다.
- 경우
libfoo에 따라 libbar풋 올바르게 다음 연결, libfoo전 libbar.
- 귀하의 연결이 실패
undefined reference to 뭔가 오류가 발생합니다.
- 그러나 모든 정의되지 않은 뭔가 들 당신이 가지고있는 헤더 파일에 선언 된
#includeD를 당신이 연결되는 라이브러리에 정의 된 사실이다.
예제는 C에 있습니다. C ++ 일 수도 있습니다.
직접 만든 정적 라이브러리와 관련된 최소한의 예
my_lib.c
#include "my_lib.h"
#include <stdio.h>
void hw(void)
{
puts("Hello World");
}
my_lib.h
#ifndef MY_LIB_H
#define MT_LIB_H
extern void hw(void);
#endif
eg1.c
#include <my_lib.h>
int main()
{
hw();
return 0;
}
정적 라이브러리를 빌드하십시오.
$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o
프로그램을 컴파일하십시오.
$ gcc -I. -c -o eg1.o eg1.c
당신은 그것을 연결하려고 시도 libmy_lib.a하고 실패합니다 :
$ gcc -o eg1 -L. -lmy_lib eg1.o
eg1.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status
한 단계에서 컴파일하고 링크하면 다음과 같은 결과가 나타납니다.
$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
/tmp/ccQk1tvs.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status
공유 시스템 라이브러리 인 압축 라이브러리와 관련된 최소한의 예 libz
eg2.c
#include <zlib.h>
#include <stdio.h>
int main()
{
printf("%s\n",zlibVersion());
return 0;
}
프로그램을 컴파일하십시오 :
$ gcc -c -o eg2.o eg2.c
프로그램을 연결 libz하고 실패하십시오.
$ gcc -o eg2 -lz eg2.o
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status
한 번에 컴파일하고 링크하면 동일합니다.
$ gcc -o eg2 -I. -lz eg2.c
/tmp/ccxCiGn7.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status
그리고 예제 2의 변형은 pkg-config다음 과 같습니다.
$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
무슨 일이야?
프로그램을 만들기 위해 링크하려는 일련의 객체 파일 및 라이브러리에서 라이브러리를 참조하는 객체 파일 앞에 라이브러리를 배치합니다. 라이브러리 를 참조하는 오브젝트 파일 뒤에 라이브러리를 배치해야 합니다.
예제 1을 올바르게 연결하십시오.
$ gcc -o eg1 eg1.o -L. -lmy_lib
성공:
$ ./eg1
Hello World
예제 2를 올바르게 연결하십시오.
$ gcc -o eg2 eg2.o -lz
성공:
$ ./eg2
1.2.8
예제 2 pkg-config변형을 올바르게 연결하십시오 .
$ gcc -o eg2 eg2.o $(pkg-config --libs zlib)
$ ./eg2
1.2.8
설명
읽기는 여기에서 선택 사항입니다 .
기본적으로 GCC에서 생성 한 링크 명령은 배포판에서 링크의 파일을 명령 줄 순서대로 왼쪽에서 오른쪽으로 사용합니다. 파일이 무언가를 참조
하고 이에 대한 정의를 포함하지 않는 것을 발견하면 파일 의 오른쪽에있는 정의를 검색합니다. 결국 정의를 찾으면 참조가 해결됩니다. 끝에 참조가 해결되지 않은 상태로 남아 있으면 연결이 실패합니다. 링커는 뒤로 검색하지 않습니다.
먼저 정적 라이브러리가있는 예제 1my_lib.a
정적 라이브러리는 객체 파일의 색인화 된 아카이브입니다. 링커가 -lmy_lib링크 순서를 찾아서 이것이 정적 라이브러리를 참조한다는 ./libmy_lib.a것을 알아 내면 프로그램에 객체 파일이 필요한지 여부를 알고 싶어합니다 libmy_lib.a.
단지 객체 파일에 있습니다 libmy_lib.a즉 my_lib.o,과에 정의 된 단 한 가지있다 my_lib.o즉 기능은 hw.
링커는 프로그램 my_lib.o이 이미 프로그램에 hw추가 한 하나 이상의 객체 파일에서 프로그램이 참조하고 있다는 것을 이미 알고 있고 이미 추가 한 객체 파일에 에 대한 정의 hw.
이것이 사실이라면 링커는 my_lib.o라이브러리에서 사본을 추출 하여 프로그램에 추가합니다. 그런 다음 프로그램에 대한 정의가 포함되어 hw있으므로 참조 hw가 해결 됩니다.
프로그램을 연결하려고 할 때
$ gcc -o eg1 -L. -lmy_lib eg1.o
링커 는 eg1.o 프로그램 을 볼 때
프로그램에 추가되지 않았습니다-lmy_lib . 그 시점에서 보지 않았기 때문에 eg1.o. 여러분의 프로그램은 아직에 대한 참조가되지 않습니다 hw: 그것은 아직 언급하지 않습니다 전혀를 , 모든 참조를 만든다이에 있기 때문에 eg1.o.
따라서 링커는 my_lib.o프로그램에 추가하지 않으며 더 이상 사용하지 않습니다 libmy_lib.a.
그런 다음을 찾아 eg1.o프로그램으로 추가합니다. 연결 순서의 개체 파일은 항상 프로그램에 추가됩니다. 이제 프로그램은에 대한 참조를 작성 hw하고에 대한 정의를 포함하지 않습니다 hw. 그러나 연결 순서에 누락 된 정의를 제공 할 수있는 것은 없습니다. 참고로 hw끝나는 미해결 및 링크 실패.
두 번째, 예 2 , 공유 라이브러리libz
공유 라이브러리는 객체 파일 또는 이와 유사한 것의 아카이브가 아닙니다. 함수 가없는 프로그램 과 비슷하지만 main대신 정의하는 여러 개의 다른 기호를 노출하여 다른 프로그램이 런타임에 사용할 수 있습니다.
대부분의 리눅스 배포판 오늘은 GCC 툴체인 그래서 그 언어 드라이버 (구성 gcc, g++, gfortran시스템 링커 (지시한다 등) ld온 링크 공유 라이브러리) 등의 필요에 기초를. 그 배포판 중 하나가 있습니다.
이것은 링커가 -lz링키지 순서에서 찾을 때 이것이 공유 라이브러리 (예 : 공유 라이브러리)를 /usr/lib/x86_64-linux-gnu/libz.so참조한다는 것을 알면 아직 정의되지 않은 프로그램에 추가 된 참조에 정의가 있는지 여부를 알고 싶어한다는 의미입니다. 에 의해 수출libz
이것이 사실이라면 링커는 청크를 복사하지 않고libz 프로그램에 추가 하지 않습니다 . 대신 프로그램 코드를 닥터하여 다음과 같이 할 것입니다.
프로그램이에 의해 내 보낸 정의가있는 한 가지 libz, 즉 함수 zlibVersion가에서 한 번만 참조되는 함수 를 참조하려고 eg2.c합니다. 링커가 해당 참조를 프로그램에 추가 한 후로 내 보낸 정의를 찾으면 libz참조가 해결됩니다.
그러나 프로그램을 다음과 같이 연결하려고하면 :
gcc -o eg2 -lz eg2.o
링커 발견 때 이벤트의 순서는 점에서 실시 예 1과 같은 단지 같은 방법으로 잘못 -lz,이없는 어떤 프로그램에서 아무것도에 대한 참조 : 그들은 모두에 eg2.o아직 보이지 않았다. 따라서 링커는에 대해 사용하지 않기로 결정합니다 libz. 에 도달 eg2.o하면 프로그램에 추가 한 다음에 대한 정의되지 않은 참조가 있으면 zlibVersion연결 시퀀스가 완료됩니다. 해당 참조가 해결되지 않고 연결이 실패합니다.
마지막으로, pkg-config예 2 의 변형은 이제 명백한 설명이다. 쉘 확장 후 :
gcc -o eg2 $(pkg-config --libs zlib) eg2.o
된다 :
gcc -o eg2 -lz eg2.o
다시 예제 2입니다.
예제 1에서는 문제를 재현 할 수 있지만 예제 2에서는 재현 할 수 없습니다
연계 :
gcc -o eg2 -lz eg2.o
당신을 위해 잘 작동합니다!
(또는 : 페도라 23에서는 링크가 잘 작동했지만 우분투 16.04에서는 실패했습니다)
연결이 작동하는 배포판 이 필요에 따라 공유 라이브러리를 연결하도록 GCC 툴체인을 구성하지 않는 배포판 중 하나이기 때문 입니다.
예전에는 유닉스 계열 시스템이 다른 규칙으로 정적 라이브러리와 공유 라이브러리를 연결하는 것이 일반적이었습니다. 연결 시퀀스의 정적 라이브러리는 예제 1에서 설명한 필요에 따라 연결되었지만 공유 라이브러리는 무조건 연결되었습니다.
링커는 프로그램에서 공유 라이브러리가 필요한지 여부를 고려할 필요가 없으므로 링크 타임에 경제적입니다. 공유 라이브러리 인 경우 링크하십시오. 그리고 대부분의 연계에서 대부분의 라이브러리는 공유 라이브러리입니다. 그러나 단점도 있습니다.
공유 라이브러리가 필요하지 않더라도 공유 라이브러리를 프로그램과 함께로드 할 수 있기 때문에 런타임에 비 경제적 입니다.
정적 및 공유 라이브러리에 대한 다른 연결 규칙이 있는지 여부를 알 수 없습니다 미숙 프로그래머로 혼동 할 수 있습니다 -lfoo자신의 연계가 해결하는 것입니다에 /some/where/libfoo.a하거나 /some/where/libfoo.so, 어쨌든 공유 및 정적 라이브러리의 차이를 이해하지 않을 수 있습니다.
이 절충안은 오늘날 제도적 상황을 초래했습니다. 일부 배포판에서는 필요에 따라
원칙이 모든 라이브러리에 적용 되도록 공유 라이브러리에 대한 GCC 연계 규칙을 변경했습니다 . 일부 배포판은 구식 방식을 고수했습니다.
동시에 컴파일하고 링크해도이 문제가 계속 발생하는 이유는 무엇입니까?
내가 방금 할 경우 :
$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
반드시 gcc는 eg1.c먼저 컴파일 한 다음 결과 객체 파일을로 연결해야합니다 libmy_lib.a. 링크를 할 때 객체 파일이 필요한지 어떻게 알 수 있습니까?
단일 명령을 사용하여 컴파일하고 연결해도 연결 순서의 순서는 변경되지 않기 때문입니다.
위의 명령을 실행하면 gcc컴파일 + 연결이 필요하다는 것을 알 수 있습니다. 그래서 무대 뒤에서, 그것은 컴파일 명령을 생성하고, 그것을 실행 후 연결 명령을 생성하고, 것처럼, 그것을 실행 당신이 두 개의 명령을 실행했다 :
$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o
그래서 링크는 경우가하는 것처럼하지 않는 두 명령을 실행합니다. 실패에서 눈에 띄는 차이점은 gcc가 컴파일 + 링크 사례에서 임시 객체 파일을 생성했다는 것 eg1.o입니다. 우리는보다:
/tmp/ccQk1tvs.o: In function `main'
대신에:
eg1.o: In function `main':
또한보십시오
상호 의존적 인 링크 된 라이브러리가 지정된 순서가 잘못되었습니다
상호 의존적 인 라이브러리를 잘못된 순서 로 놓는 것은 정의를 제공 하는 파일보다 나중에 링크에 나오는 것들에 대한 정의 가 필요한 파일을 얻을 수있는 한 가지 방법 일뿐 입니다. 라이브러리를 참조하는 오브젝트 파일 앞에 라이브러리를 두는 것도 같은 실수를하는 또 다른 방법입니다.