Bağlantınız kitaplıkları, bunlara başvuran nesne dosyalarından önce tüketir
- Programınızı derlemeye ve GCC araç zincirine bağlamaya çalışıyorsunuz.
- Bağlantınız tüm gerekli kitaplıkları ve kitaplık arama yollarını belirtir
- Eğer
libfoobağlıdır libbar, sonra bağlantı doğru koyar libfooöncelibbar .
- Bağlantınız bir şeyle başarısız oluyor
undefined reference to hataları.
- Ancak tüm tanımlanmamış şeyler , sahip olduğunuz başlık dosyalarında bildirilir
#includeve aslında bağladığınız kütüphanelerde tanımlanır.
Örnekler C cinsindendir. Aynı şekilde C ++ olabilirler.
Kendiniz inşa ettiğiniz statik kütüphaneyi içeren minimal bir örnek
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;
}
Statik kitaplığınızı oluşturursunuz:
$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o
Programınızı derlersiniz:
$ gcc -I. -c -o eg1.o eg1.c
Bağlantı kurmaya çalışın libmy_lib.ave başarısız olun:
$ 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
Bir adımda derleyip bağlarsanız aynı sonuç, örneğin:
$ 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
Paylaşılan sistem kitaplığı olan sıkıştırma kitaplığını içeren en az örnek libz
eg2.c
#include <zlib.h>
#include <stdio.h>
int main()
{
printf("%s\n",zlibVersion());
return 0;
}
Programınızı derleyin:
$ gcc -c -o eg2.o eg2.c
Programınızı bağlamayı deneyin libzve başarısız olun:
$ 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
Bir seferde derleyip bağlarsanız aynı:
$ 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
Ve örnek 2'de aşağıdakileri içeren bir varyasyon pkg-config:
$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
Ne yapıyorsun?
Programınızı oluşturmak için bağlamak istediğiniz nesne dosyaları ve kitaplıklar sırasında, kitaplıkları bunlara başvuran nesne dosyalarının önüne yerleştirirsiniz. Sen kütüphaneleri yerleştirmeniz gerekir sonra onlara bakın nesne dosyaları.
Örnek 1'i doğru bağlayın:
$ gcc -o eg1 eg1.o -L. -lmy_lib
Başarı:
$ ./eg1
Hello World
Örnek 2'yi doğru şekilde bağlayın:
$ gcc -o eg2 eg2.o -lz
Başarı:
$ ./eg2
1.2.8
Örnek 2 pkg-configvaryasyonunu doğru şekilde bağlayın:
$ gcc -o eg2 eg2.o $(pkg-config --libs zlib)
$ ./eg2
1.2.8
Açıklama
Buradan okuma isteğe bağlıdır .
Varsayılan olarak, dağıtımınızda GCC tarafından oluşturulan bir bağlantı komutu, bağlantıdaki dosyaları komut satırı sırasında soldan sağa tüketir. Bir dosyanın bir şeye atıfta bulunduğunu tespit ettiğinde
ve bunun için bir tanım içermediğini tespit ettiğinde, sağdaki dosyalarda bir tanım arayacaktır. Sonunda bir tanım bulursa, başvuru çözülür. Sonunda herhangi bir referans çözülmezse, bağlantı başarısız olur: bağlayıcı geriye doğru arama yapmaz.
İlk olarak, örnek 1 , statik kitaplıklamy_lib.a
Statik kitaplık, nesne dosyalarının dizinlenmiş bir arşividir. Bağlayıcı -lmy_libbağlantı sırasında bulduğunda ve bunun statik kitaplığa ./libmy_lib.abaşvurduğunu anladığında, programınızın nesne dosyalarından herhangi birine ihtiyacı olup olmadığını bilmek ister libmy_lib.a.
Sadece nesne dosyası içinde var libmy_lib.ayani my_lib.o, ve tanımlanan tek bir şey var my_lib.o, yani işlevhw .
Bağlayıcı, programınızın my_lib.oyalnızca programınızın başvurduğunu zaten biliyorsa, programa hwzaten eklediği bir veya daha fazla nesne dosyasında ve zaten eklenmiş nesne dosyalarının hiçbirinin bir tanımı hw,.
Bu doğruysa, bağlayıcı my_lib.okitaplığın bir kopyasını ayıklayıp programınıza ekler. Ardından, programı için bir tanım içeriyor hw, bu yüzden onun referanslar için hwvardır çözüldü .
Programı aşağıdaki gibi bağlamaya çalıştığınızda:
$ gcc -o eg1 -L. -lmy_lib eg1.o
linker gördüğünde
programa eklememiştir . Çünkü o noktada, görmedi . Programınız henüz ilişkin referansları yapmaz : henüz herhangi bir referans yapmaz hiç , bütün referanslar bunu yapar içindedir çünkü .eg1.o -lmy_libeg1.ohweg1.o
Bu yüzden linker my_lib.oprograma eklenmez ve bunun için başka kullanımı yoktur libmy_lib.a.
Sonra bulur eg1.ove program olarak ekler. Bağlantı dizisindeki bir nesne dosyası her zaman programa eklenir. Şimdi, program bir referans yapar hwve bir tanımı içermez hw; ancak bağlantı sırasında eksik tanım sağlayabilecek hiçbir şey kalmaz. Referans hwkadar uçları çözülmemiş ve bağlantı başarısız olur.
İkinci olarak, örnek 2 , paylaşılan kitaplıklalibz
Paylaşılan kitaplık, nesne dosyalarının veya bunun gibi bir şeyin arşivi değildir. Daha çok bir işlevi olmayan bir programa benziyor mainve bunun yerine tanımladığı diğer birçok sembolü ortaya çıkarıyor, böylece diğer programlar bunları çalışma zamanında kullanabiliyor.
Birçok Linux dağıtımları bugün GCC araç zinciri böylece onun dil sürücülerini (yapılandırmak gcc, g++, gfortransistem bağlayıcı (talimat vs) ldbir bağlantısını paylaşılan kütüphanelere) olarak ihtiyaç duyulan bazda. Bu dağıtımlardan birine sahipsiniz.
Bu, linker -lzbağlantı sırasında bulduğunda ve bunun paylaşılan kütüphaneye (örneğin) /usr/lib/x86_64-linux-gnu/libz.soatıfta bulunduğunu anladığında, programınıza henüz tanımlanmamış herhangi bir referansın tanımlanmamış olup olmadığını bilmek istediği anlamına gelir. tarafından ihraç edildilibz
Eğer bu doğruysa, o zaman bağlayıcı olacak değil dışına herhangi parçalarını kopyalamak libzve programa ekleyebilirsiniz; bunun yerine, sadece programınızın kodunu doktor olacak, böylece: -
Çalışma zamanında, sistem program yükleyicisi, programınızın bir kopyasını libzher yüklediğinde, programınızla aynı sürece bir kopyasını yükler.
Çalışma zamanında, programınız tanımlanmış bir şeye
libzbaşvurduğunda, bu başvuru libzaynı işlemde kopyasının dışa aktardığı tanımı kullanır .
Programınız dışa aktarılan bir tanıma sahip olan tek bir şeye libz, yani zlibVersionsadece bir kez atıfta bulunulan işleve atıfta bulunmak istiyor eg2.c. Bağlayıcı bu referansı programınıza ekler ve ardından tarafından dışa aktarılan tanımı bulursa libz, başvuru çözülür
Ancak programı aşağıdaki gibi bağlamaya çalıştığınızda:
gcc -o eg2 -lz eg2.o
Bağlayıcı bulgular zaman olayların sırası noktasında örnek 1. olduğu gibi sadece aynı şekilde yanlıştır -lzvardır hiçbir programda hiçbir şeye referanslar: hepsi içindedir eg2.ohenüz görülmedi. Bu yüzden bağlayıcı, işe yaramayacağına karar verir libz. Ulaştığında eg2.o, programa ekler ve daha sonra referansı tanımlanmamışsa zlibVersion, bağlantı dizisi tamamlanır; bu başvuru çözümlenmedi ve bağlantı başarısız oldu.
Son olarak, pkg-configörnek 2'deki varyasyonun şimdi açık bir açıklaması vardır. Kabuk açıldıktan sonra:
gcc -o eg2 $(pkg-config --libs zlib) eg2.o
dönüşür:
gcc -o eg2 -lz eg2.o
bu yine örnek 2'dir.
Örnek 1'deki sorunu yeniden oluşturabilirim, ancak örnek 2'de değil
Bağlantı:
gcc -o eg2 -lz eg2.o
senin için iyi çalışıyor!
(Veya: Bu bağlantı, Fedora 23'te sizin için iyi çalıştı, ancak Ubuntu 16.04'te başarısız oldu)
Bunun nedeni, bağlantının çalıştığı dağıtımın, GCC araç zincirini paylaşılan kütüphaneleri gerektiği gibi bağlamak için yapılandırmayanlardan biri olmasıdır .
O günlerde, unix benzeri sistemlerin statik ve paylaşılan kütüphaneleri farklı kurallara bağlaması normaldi. Bir bağlantı sekansındaki statik kütüphaneler, örnek l'de açıklanan ihtiyaca göre bağlandı, ancak paylaşılan kütüphaneler koşulsuz olarak bağlandı.
Bağlayıcının program tarafından paylaşılan bir kitaplığa gerek olup olmadığını düşünmesi gerekmediğinden, bu davranış bağlantı zamanında ekonomiktir: eğer paylaşılan bir kitaplıksa, onu bağlayın. Ve çoğu bağlantıdaki çoğu kütüphane paylaşılan kütüphanelerdir. Ama dezavantajları da var: -
Çalışma zamanında ekonomik değildir , çünkü ihtiyaç duyulmasa bile paylaşılan kitaplıkların bir programla birlikte yüklenmesine neden olabilir.
Statik ve paylaşılan kütüphaneleri için farklı bağlantı kuralları olmadığını bilmiyor olabilir uzman olmayan programcılar, kafa karıştırıcı olabilir -lfooonların bağlantı isteği ve kararı gidiyor içinde /some/where/libfoo.aveya /some/where/libfoo.sove yine paylaşılan ve statik kütüphaneleri arasındaki farkı anlamayabilir.
Bu değiş tokuş bugün şizmatik duruma yol açtı. Bazı dağıtımlar, paylaşılan kütüphaneler için GCC bağlantı kurallarını değiştirdi, böylece ihtiyaç
ilkesi tüm kütüphaneler için geçerlidir. Bazı dağıtımlar eski yolla sıkıştı.
Aynı anda derleyip bağlasam bile neden bu sorunu alıyorum?
Sadece yaparsam:
$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
şüphesiz gcc önce derlemek eg1.cve sonra ortaya çıkan nesne dosyasını bağlamak zorundadır libmy_lib.a. Peki, bağlantı yaparken nesne dosyasının gerekli olduğunu nasıl bilemez?
Çünkü tek bir komutla derleme ve bağlantı, bağlantı dizisinin sırasını değiştirmez.
Yukarıdaki komutu çalıştırdığınızda, gccderleme + bağlantı istediğinizi anlar. Yani perde arkasında, bir derleme komutu oluşturur ve çalıştırır, daha sonra bir bağlantı komutu oluşturur ve sanki onu çalıştırır sen iki komut kaçmıştı:
$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o
Yani bağlantı eğer o yaptığı gibi başarısız mı bu iki komutları çalıştırın. Hatada fark ettiğiniz tek fark, gcc'nin derleme + bağlantı durumunda geçici bir nesne dosyası oluşturmasıdır, çünkü kullanmasını söylemezsiniz eg1.o. Görürüz:
/tmp/ccQk1tvs.o: In function `main'
onun yerine:
eg1.o: In function `main':
Ayrıca bakınız
Birbirine bağlı bağlantılı kitaplıkların belirtilme sırası yanlış
Birbirine bağımlı kütüphaneleri yanlış sıraya koymak , bağlantıları sağlayan dosyalardan daha sonra bağlantıda daha sonra gelen şeylerin tanımlarına ihtiyaç duyan dosyaları almanın sadece bir yoludur . Kütüphaneleri kendilerine başvuran nesne dosyalarının önüne koymak da aynı hatayı yapmanın başka bir yoludur.