Warum müssen Sie die Mathematik-Bibliothek in C verknüpfen?

Question

Wenn ich oder in einem C-Programm einfüge, muss ich diese beim Kompilieren nicht verknüpfen, aber ich muss verknüpfen, beispielsweise mit -lm mit GCC:

gcc test.c -o test -lm

Was ist der Grund dafür? Warum muss ich die Mathematikbibliothek explizit verknüpfen, aber nicht die anderen Bibliotheken?

Answer 1

Es gibt eine gründliche Diskussion über das Verlinken externer Bibliotheken in Eine Einführung in GCC - Verlinken mit externen Bibliotheken. Wenn eine Bibliothek zu den Standardbibliotheken gehört (wie stdio), müssen Sie dem Compiler (eigentlich dem Linker) nicht angeben, dass sie verlinkt werden sollen.

Nachdem ich einige der anderen Antworten und Kommentare gelesen habe, glaube ich, dass die libc.a-Referenz und die darin verlinkte libm-Referenz viel darüber aussagen, warum die beiden getrennt sind.

Beachten Sie, dass viele der Funktionen in 'libm.a' (die Mathematik-Bibliothek) in 'math.h' definiert sind, aber nicht in libc.a vorhanden sind. Einige sind es, was verwirrend sein kann, aber die Faustregel lautet wie folgt - die C-Bibliothek enthält diejenigen Funktionen, die von ANSI vorgeschrieben sind und daher nicht das -lm benötigen, wenn Sie nur ANSI-Funktionen verwenden. Im Gegensatz dazu enthält 'libm.a' mehr Funktionen und unterstützt zusätzliche Funktionalitäten wie den matherr-Callback und die Einhaltung mehrerer alternativer Verhaltensstandards im Falle von FP-Fehlern. Weitere Details finden Sie im Abschnitt libm.

Answer 2

Wie ephemient sagte, wird die C-Bibliothek libc standardmäßig verknüpft und diese Bibliothek enthält die Implementierungen von stdlib.h, stdio.h und mehreren anderen Standard-Headerdateien. Nur um hinzuzufügen, gemäß "Eine Einführung in GCC" lautet der Linker-Befehl für ein einfaches "Hello World"-Programm in C wie folgt:

ld -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o /usr/libgcc-lib/i686/3.3.1/crtbegin.o
-L/usr/lib/gcc-lib/i686/3.3.1 hello.o -lgcc -lgcc_eh -lc
-lgcc -lgcc_eh /usr/lib/gcc-lib/i686/3.3.1/crtend.o /usr/lib/crtn.o

Beachten Sie die Option -lc in der dritten Zeile, die die C-Bibliothek verknüpft.

Answer 3

Ich glaube, es ist ziemlich willkürlich. Man muss irgendwo eine Grenze ziehen (welche Bibliotheken standardmäßig sind und welche angegeben werden müssen).

Es gibt Ihnen die Möglichkeit, sie durch eine andere zu ersetzen, die die gleichen Funktionen hat, aber ich glaube nicht, dass es sehr häufig vorkommt.

Ich denke, dass GCC dies tut, um die Abwärtskompatibilität mit dem ursprünglichen cc ausführbar zu erhalten. Meine Vermutung, warum cc dies tut, ist wegen der Bauzeit - cc wurde für Maschinen mit weit weniger Leistung als wir jetzt haben geschrieben. Viele Programme haben keine Gleitkomma-Mathematik, und wahrscheinlich wurde jede Bibliothek, die nicht häufig verwendet wurde, standardmäßig entfernt. Ich vermute, dass die Bauzeit des Unix-Betriebssystems und der Tools, die damit einhergehen, die treibende Kraft waren.

Answer 4

Wenn ich stdlib.h oder stdio.h einfüge, muss ich diese nicht verknüpfen, aber wenn ich kompiliere, muss ich verknüpfen:

stdlib.h, stdio.h sind die Header-Dateien. Sie werden zu Ihrem Komfort eingefügt. Sie prognostizieren nur, welche Symbole verfügbar werden, wenn Sie die entsprechende Bibliothek verknüpfen. Die Implementierungen befinden sich in den Bibliotheksdateien, das ist der Ort, an dem die Funktionen wirklich existieren.

Das Einbinden von math.h ist nur der erste Schritt, um Zugriff auf alle mathematischen Funktionen zu erhalten.

Sie müssen auch nicht gegen libm verknüpfen, wenn Sie dessen Funktionen nicht verwenden, selbst wenn Sie ein #include machen, was nur ein informativer Schritt für Sie und den Compiler bezüglich der Symbole ist.

stdlib.h, stdio.h verweisen auf Funktionen, die in libc verfügbar sind, was zufällig immer verknüpft wird, damit der Benutzer dies nicht selbst tun muss.

Answer 5

Ich würde vermuten, dass dies eine Möglichkeit ist, Anwendungen, die es überhaupt nicht nutzen, etwas effizienter zu machen. Hier ist meine Überlegung dazu.

x86-Betriebssysteme (und ich nehme an, auch andere) müssen den FPU-Zustand beim Kontextwechsel speichern. Die meisten Betriebssysteme kümmern sich jedoch nur darum, diesen Zustand zu speichern/wiederherzustellen, nachdem die Anwendung versucht hat, die FPU zum ersten Mal zu verwenden.

Zusätzlich dazu gibt es wahrscheinlich einige grundlegende Codes in der Mathematikbibliothek, die den FPU auf einen vernünftigen Ausgangszustand setzen, wenn die Bibliothek geladen wird.

Also, wenn du überhaupt keinen Mathematikcode einbindest, wird nichts davon passieren. Daher muss das Betriebssystem überhaupt keinen FPU-Zustand speichern/wiederherstellen, was die Kontextwechsel etwas effizienter macht.

Nur eine Vermutung jedoch.

Das gleiche Grundprinzip gilt auch für Nicht-FPU-Fälle (das Grundprinzip war, Anwendungen, die libm nicht verwenden, etwas effizienter zu machen).

Zum Beispiel, wenn es ein Soft-FPU gab, das wahrscheinlich in den frühen Tagen von C war. Dann könnte es viele große (und langsame, wenn es verwendet wurde) Codes verhindern, die unnötigerweise verknüpft werden.

Zusätzlich, wenn nur eine statische Verknüpfung verfügbar ist, dann gilt ein ähnliches Argument, dass es die Ausführungsgrößen und Kompilierzeiten niedrig halten würde.