Ich habe eine gemeinsam genutzte Bibliothek, die mit einer anderen gemeinsam genutzten Bibliothek (Drittanbieter) verknüpft ist. Meine gemeinsam genutzte Bibliothek wird dann mit dlopen in meine Anwendung geladen. All dies funktioniert gut (vorausgesetzt, die Dateien befinden sich im richtigen Pfad usw.).
Nun besteht das Problem darin, dass ich beim Verknüpfen meiner Bibliothek nicht einmal angeben muss, dass eine Verknüpfung mit der gemeinsam genutzten Bibliothek eines Drittanbieters hergestellt werden soll. GCC akzeptiert es, ohne Fehler über undefinierte Verweise zu melden. Also, die Frage; wie kann ich GCC zwingen, mich über undefinierte Referenzen zu benachrichtigen?
Wenn ich meine Bibliothek (vorübergehend) in eine ausführbare Datei ändere, erhalte ich undefinierte Verweise (wenn ich die Bibliothek nicht an den Linker weitergebe). (Funktioniert gut, wenn ich es spezifiziere.)
Dh folgendes wird gemacht:
g++ -fPIC -shared -o libb.so b.o
g++ -fPIC -shared -o liba.so a.o
g++ -o a.exe a.cpp
Wobei die zweite Zeile KEINEN Fehler ausgibt und die dritte Zeile sich über eine undefinierte Referenz beschwert.
Beispielcode:
Ah:
class a
{
public:
void foobar();
};
a.cpp:
#include "a.h"
#include "b.h"
void a::foobar()
{
b myB;
myB.foobar();
}
int main()
{
a myA; myA.foobar();
}
bh:
class b
{
public:
void foobar();
};
b.cpp:
#include "b.h"
void b::foobar()
{
}
-Wl,--no-undefined Die Linker-Option kann beim Erstellen einer gemeinsam genutzten Bibliothek verwendet werden. Undefinierte Symbole werden als Linker-Fehler angezeigt.
g++ -shared -Wl,-soname,libmylib.so.5 -Wl,--no-undefined
-o libmylib.so.1.1 mylib.o -lthirdpartylib
Nach mehr Recherche wurde mir klar, wie das Zeug funktioniert. Es gibt zwei Linker-Optionen, um undefinierte Symbole gemeinsam genutzter Bibliotheken zu manipulieren:
Das erste ist --no-undefined. Es meldet die nicht aufgelösten Symbole, die nicht sofort aufgelöst werden, in der Verknüpfungsphase. Sofern das Symbol nicht in einer gemeinsam genutzten Bibliothek gefunden wird, gegen die verlinkt ist, entweder manuell (mit -l Schalter) oder automatisch (libgcc_sC++-Laufzeit; libcC-Laufzeit; ld-linux-**.soDienstprogramme für dynamische Linker) ausgewählt, --no-undefined meldet es als Fehler. Das ist der Schlüssel, den der Fragesteller brauchte.
Es gibt einen anderen Schlüssel, --no-allow-shlib-undefined (dessen Beschreibung auch suggeriert --no-undefined). Es prüft, ob Definitionen in den gemeinsam genutzten Bibliotheken vorhanden sind mit der Sie Ihre gemeinsam genutzte Bibliothek verknüpfen sind zufrieden. Dieser Schlüssel ist in dem in diesem Thema gezeigten Fall von geringem Nutzen, kann aber nützlich sein. Es hat jedoch seine eigenen Hindernisse.
Die Manpage bietet einige Gründe dafür, warum es nicht standardmäßig ist:
--allow-shlib-undefined
--no-allow-shlib-undefined
Allows (the default) or disallows undefined symbols in shared
libraries (It is meant, in shared libraries _linked_against_, not the
one we're creating!--Pavel Shved). This switch is similar to --no-un-
defined except that it determines the behaviour when the undefined
symbols are in a shared library rather than a regular object file. It
does not affect how undefined symbols in regular object files are
handled.
The reason that --allow-shlib-undefined is the default is that the
shared library being specified at link time may not be the same as
the one that is available at load time, so the symbols might actually
be resolvable at load time. Plus there are some systems, (eg BeOS)
where undefined symbols in shared libraries is normal. (The kernel
patches them at load time to select which function is most appropri-
ate for the current architecture. This is used for example to dynam-
ically select an appropriate memset function). Apparently it is also
normal for HPPA shared libraries to have undefined symbols.
Die Sache ist, dass das oben Gesagte beispielsweise auch für Linux-Systeme gilt, in denen einige der internen Routinen der gemeinsam genutzten Bibliothek implementiert sind ld-linux.so, der dynamische Loader (er ist sowohl ausführbar als auch gemeinsam genutzte Bibliothek). Wenn Sie es nicht irgendwie verlinken, erhalten Sie so etwas:
/lib64/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE'
/lib64/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE'
/usr/lib64/gcc/x86_64-suse-linux/4.3/libstdc++.so: undefined reference to `__tls_get_addr@GLIBC_2.3'
/lib64/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE'
/lib64/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE'
Dies sind undefinierte Verweise vom Ladeprogramm, ld-linux.so. Es ist plattformspezifisch (auf meinem System ist beispielsweise der richtige Loader /lib64/ld-linux-x86-64.so). Sie können den Loader mit Ihrer Bibliothek verknüpfen und sogar die oben gezeigten kniffligen Referenzen überprüfen:
g++ -fPIC -shared -o liba.so a.o -Wl,--no-allow-shlib-undefined /lib64/ld-linux-x86-64.so.2
.
