Twoje połączenie zużywa biblioteki przed plikami obiektowymi, które się do nich odnoszą
- Próbujesz skompilować i połączyć swój program z zestawem narzędzi GCC.
- Twój link określa wszystkie niezbędne biblioteki i ścieżki wyszukiwania bibliotek
- Jeśli
libfoozależy od libbartego, twój link poprawnie wstawia libfoowcześniej libbar.
- Twoje połączenie zawiedzie z
undefined reference to czymś błędami.
- Ale wszystkie nieokreślone coś s deklarowane są w plikach nagłówkowych masz
#includeD i faktycznie są zdefiniowane w bibliotekach, które są linkami.
Przykłady znajdują się w C. Równie dobrze mogłyby to być C ++
Minimalny przykład dotyczący biblioteki statycznej, którą sam zbudowałeś
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;
}
Budujesz swoją bibliotekę statyczną:
$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o
Kompilujesz swój program:
$ gcc -I. -c -o eg1.o eg1.c
Próbujesz połączyć go z libmy_lib.ai nie powiedzie się:
$ 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
Ten sam wynik, jeśli kompilujesz i łączysz w jednym kroku, na przykład:
$ 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
Minimalny przykład dotyczący wspólnej biblioteki systemowej, biblioteki kompresji libz
eg2.c
#include <zlib.h>
#include <stdio.h>
int main()
{
printf("%s\n",zlibVersion());
return 0;
}
Skompiluj swój program:
$ gcc -c -o eg2.o eg2.c
Spróbuj połączyć swój program libzi zawieść:
$ 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
To samo, jeśli kompilujesz i łączysz za jednym razem:
$ 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
I wariant na przykładzie 2 obejmujący pkg-config:
$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
Co robisz źle
W sekwencji plików obiektowych i bibliotek, które chcesz połączyć w celu utworzenia programu, umieszczasz biblioteki przed plikami obiektowymi, które się do nich odnoszą. Musisz umieścić biblioteki po plikach obiektowych, które się do nich odnoszą.
Podłącz przykład 1 poprawnie:
$ gcc -o eg1 eg1.o -L. -lmy_lib
Sukces:
$ ./eg1
Hello World
Podłącz przykład 2 poprawnie:
$ gcc -o eg2 eg2.o -lz
Sukces:
$ ./eg2
1.2.8
Połącz pkg-configpoprawnie przykładową odmianę 2 :
$ gcc -o eg2 eg2.o $(pkg-config --libs zlib)
$ ./eg2
1.2.8
Wyjaśnienie
Odczytywanie jest odtąd opcjonalne .
Domyślnie polecenie powiązania wygenerowane przez GCC w twojej dystrybucji zużywa pliki w powiązaniu od lewej do prawej w sekwencji wiersza poleceń. Gdy stwierdzi, że plik odnosi się do czegoś
i nie zawiera definicji tego, szuka definicji w plikach po prawej stronie. Jeśli w końcu znajdzie definicję, odwołanie zostanie rozwiązane. Jeśli na końcu jakieś odniesienia pozostaną nierozwiązane, połączenie się nie powiedzie: linker nie szuka wstecz.
Najpierw przykład 1 ze statyczną bibliotekąmy_lib.a
Biblioteka statyczna to zindeksowane archiwum plików obiektowych. Gdy linker znajdzie -lmy_libsekwencję łączenia i ./libmy_lib.azorientuje się, że odnosi się to do biblioteki statycznej , chce wiedzieć, czy twój program potrzebuje plików obiektowych libmy_lib.a.
Jest tylko plik obiektowy libmy_lib.a, a mianowicie my_lib.o, i jest zdefiniowana tylko jedna rzecz my_lib.o, a mianowicie funkcja hw.
Linker zdecyduje, że twój program potrzebuje my_lib.owtedy i tylko wtedy, gdy już wie, że twój program się odwołuje hw, w co najmniej jednym pliku obiektowym, który już dodał do programu, i że żaden z plików obiektowych, który już dodał, nie zawiera definicja dla hw.
Jeśli to prawda, linker wyodrębni kopię my_lib.oz biblioteki i doda ją do twojego programu. Następnie twój program zawiera definicję hw, więc jego odniesienia do hwzostały rozwiązane .
Podczas próby połączenia programu, takiego jak:
$ gcc -o eg1 -L. -lmy_lib eg1.o
linker nie dodał eg1.o do programu, gdy widzi
-lmy_lib. Ponieważ w tym momencie nie widziałem eg1.o. Twój program nie ma jeszcze dokonywać żadnych odniesień do hw: to jeszcze nie dokonywać żadnych odniesień w ogóle , ponieważ wszystkie odniesienia to sprawia, że są eg1.o.
Linker nie dodaje my_lib.osię do programu i nie ma dalszego zastosowania libmy_lib.a.
Następnie znajduje eg1.oi dodaje do programu. Plik obiektowy w sekwencji łączenia jest zawsze dodawany do programu. Teraz program zawiera odniesienie hwi nie zawiera definicji hw; ale w sekwencji łączenia nie pozostało nic, co mogłoby zapewnić brakującą definicję. Odwołanie do hwkończy się nierozwiązane , a powiązanie kończy się niepowodzeniem.
Po drugie, przykład 2 , z biblioteką współdzielonąlibz
Biblioteka współdzielona nie jest archiwum plików obiektowych ani nic podobnego. Bardziej przypomina program , który nie ma mainfunkcji i zamiast tego wyświetla wiele innych symboli, które definiuje, aby inne programy mogły z nich korzystać w czasie wykonywania.
Dzisiaj wielu dystrybucjach Linuksa skonfigurować swój GCC toolchain tak, że jego sterowniki językowe ( gcc, g++, gfortranetc) poinstruować łącznikiem systemowym ( ld), aby połączyć współdzielonych bibliotek w miarę potrzeb podstawie. Masz jedną z tych dystrybucji.
Oznacza to, że gdy linker znajdzie -lzsekwencję łączenia i /usr/lib/x86_64-linux-gnu/libz.sozorientuje się, że odnosi się to do biblioteki współdzielonej (powiedzmy) , chce wiedzieć, czy jakiekolwiek odwołania dodane do programu, które nie zostały jeszcze zdefiniowane, mają definicje, które są eksportowane przezlibz
Jeśli to prawda, linker nie skopiuje żadnych fragmentów libzi nie doda ich do twojego programu; zamiast tego po prostu dokona kodu twojego programu, aby:
W czasie wykonywania program ładujący program ładuje kopię libzdo tego samego procesu, co program, za każdym razem, gdy ładuje kopię programu, aby go uruchomić.
W czasie wykonywania, ilekroć twój program odwołuje się do czegoś, co jest zdefiniowane w
libz, to odwołanie korzysta z definicji wyeksportowanej przez kopię libzw tym samym procesie.
Twój program chce odwoływać się tylko do jednej rzeczy, która ma wyeksportowaną definicję libz, a mianowicie funkcji zlibVersion, do której odwołuje się tylko raz eg2.c. Jeśli linker doda to odwołanie do programu, a następnie znajdzie wyeksportowaną definicję libz, odwołanie zostanie rozwiązane
Ale kiedy próbujesz połączyć program w następujący sposób:
gcc -o eg2 -lz eg2.o
kolejność zdarzeń jest niepoprawna w taki sam sposób jak w przykładzie 1. W momencie, gdy linker znajdzie -lz, nie ma żadnych odniesień do niczego w programie: wszystkie są w eg2.o, czego jeszcze nie widziano. Linker decyduje więc, że nie ma sensu libz. Kiedy osiągnie eg2.o, dodaje go do programu, a następnie ma niezdefiniowane odniesienie zlibVersion, sekwencja łączenia jest zakończona; to odniesienie jest nierozwiązane, a połączenie nie działa.
Wreszcie pkg-configodmiana z przykładu 2 ma teraz oczywiste wytłumaczenie. Po rozszerzeniu powłoki:
gcc -o eg2 $(pkg-config --libs zlib) eg2.o
staje się:
gcc -o eg2 -lz eg2.o
co jest znowu tylko przykładem 2.
Mogę odtworzyć problem w przykładzie 1, ale nie w przykładzie 2
Połączenie:
gcc -o eg2 -lz eg2.o
działa dobrze dla Ciebie!
(Lub: To połączenie działało dobrze dla ciebie, powiedzmy, Fedora 23, ale nie działa w Ubuntu 16.04)
Wynika to z faktu, że dystrybucja, w której działa łączenie, jest jedną z tych, które nie konfigurują łańcucha narzędzi GCC do łączenia bibliotek współdzielonych w razie potrzeby .
W tamtych czasach normalne dla systemów uniksowych było łączenie bibliotek statycznych i współdzielonych według różnych reguł. Biblioteki statyczne w sekwencji łączenia zostały połączone zgodnie z potrzebami wyjaśnionymi w przykładzie 1, ale biblioteki wspólne zostały połączone bezwarunkowo.
Takie zachowanie jest ekonomiczne w czasie połączenia, ponieważ linker nie musi zastanawiać się, czy program potrzebuje biblioteki współdzielonej: jeśli jest to biblioteka współdzielona, połącz ją. A większość bibliotek w większości powiązań to biblioteki współdzielone. Ale są też wady: -
Jest to nieopłacalne w czasie wykonywania , ponieważ może powodować ładowanie bibliotek współdzielonych wraz z programem, nawet jeśli ich nie potrzebuje.
Różne reguły łączenia dla bibliotek statycznych i współdzielonych mogą być mylące dla niedoświadczonych programistów, którzy mogą nie wiedzieć, czy -lfoow ich powiązaniu rozwiążą się /some/where/libfoo.alub nie /some/where/libfoo.so, i mogą nie rozumieć różnicy między bibliotekami współdzielonymi a statycznymi.
Ten kompromis doprowadził dziś do schizmatyckiej sytuacji. Niektóre dystrybucje zmieniły swoje reguły łączenia GCC dla bibliotek współużytkowanych, tak aby
zasada według potrzeb miała zastosowanie do wszystkich bibliotek. Niektóre dystrybucje utknęły w starym stylu.
Dlaczego wciąż mam ten problem, nawet jeśli jednocześnie kompiluję i łączę?
Jeśli tylko to zrobię:
$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
z pewnością gcc eg1.cnajpierw musi się skompilować , a następnie połączyć wynikowy plik obiektowy libmy_lib.a. Jak więc nie wiedzieć, że plik obiektowy jest potrzebny podczas łączenia?
Ponieważ kompilacja i łączenie za pomocą jednego polecenia nie zmienia kolejności sekwencji łączenia.
Po uruchomieniu powyższego polecenia gccokazuje się, że chcesz kompilację + powiązanie. Więc za kulisami generuje polecenie kompilacji i uruchamia je, a następnie generuje polecenie łączenia i uruchamia je tak, jakbyś uruchomił dwa polecenia:
$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o
Tak więc połączenie nie tak jak to robi, jeśli nie uruchomić te dwie komendy. Jedyną różnicą, którą zauważasz w przypadku niepowodzenia, jest to, że gcc wygenerował tymczasowy plik obiektowy w przypadku kompilacji + łącza, ponieważ nie mówisz, aby go używał eg1.o. Widzimy:
/tmp/ccQk1tvs.o: In function `main'
zamiast:
eg1.o: In function `main':
Zobacz też
Kolejność określania wzajemnie zależnych bibliotek połączonych jest nieprawidłowa
Umieszczenie współzależnych bibliotek w niewłaściwej kolejności to tylko jeden ze sposobów, w jaki można uzyskać pliki wymagające definicji rzeczy, które pojawią się później w powiązaniu, niż pliki, które zawierają definicje. Umieszczenie bibliotek przed odnoszącymi się do nich plikami obiektowymi to kolejny sposób na popełnienie tego samego błędu.