Bibliotheken linken
-
Hallo!
Ich hoffe ich bin mit meiner Frage in diesem Forum richtig.
Habe 2 Fragen zum g++ und Bibliotheken:
-
Wenn ich mit der Option -l eine Bibliothek angebe die gelinkt werden soll, woher weiß der Compiler dann welche Datei ich damit meine? Unter Windows gibt man dem Linker die genauen Dateinamen und Pfade an. Unter Linux habe ich aber gerade ein Beispiel für die SDL-Bibliothek ausprobiert: Da gibt man zwar die Option "-l SDL" an, eine Datei mit dem Namen SDL habe ich unter /usr/lib nicht gefunden (und auch in sonst keinem Verzeichnis). Bei der Mesa-Bibliothek ist es auch so: man gibt "-l MesaGL" an, es gibt aber keine Datei mit diesem Namen.
-
Wie compiliere ich selbst (statische) Bibliotheken, die ich dann ich anderen Programmen verwenden kann?
Gibt es unter Linux auch so etwas wie DLLs unter Windows?
Danke schonmal!
mfg
-
-
Christoph R. schrieb:
Hallo!
Ich hoffe ich bin mit meiner Frage in diesem Forum richtig.
ja
1. -llibname soll nicht getrennt angegeben werden, d.h. -lmysql ist richtig, mit -l mysql habe ich Ärger gehabt. Der Compiler interessiert sich erstmal gar nicht, wo welche es gibt, sondern der Linker, und wie er es tut, erkläre ich in Frage 2.
2. Linux kennt sowas die Windows DLLs, das sind die Shared Objects, die erkennt man am .so Dateiende. Anders als wie bei Windows, müssen diese Dateien nicht registriert werden, aber es gibt ein Paar Regeln, die sie erfüllen müssen.
1. Sie müssen sich in einem Verzeichnis befinden, das in der Variable LD_LIBRARY_PATH befindet. /lib /usr/lib, /etc/X11/lib usw sind in den meisten Fällen schon da. Man kann aber auch seine eigene Verzeichnisse eintragen. Die Datei /etc/ld.so.conf (zumindest kenne ich sie von Debian und Gentoo, weiß aber nicht, ob das jede Distri hat) ist eine Ansammlung von "lib" Verzeichnisse. Meine sieht zum Beispiel so aus:# ld.so.conf autogenerated by env-update; make all changes to # contents of /etc/env.d directory /usr/local/lib /usr/lib/opengl/nvidia/lib /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5 /usr/lib /opt/blackdown-jdk-1.4.2.01/jre/lib/i386/ /opt/blackdown-jdk-1.4.2.01/jre/lib/i386/native_threads/ /opt/blackdown-jdk-1.4.2.01/jre/lib/i386/classic/ /usr/qt/3/lib /usr/kde/3.3/lib /usr/lib/nspr /usr/lib/nss /usr/games/lib /usr/lib/fltk-1.1
Naja, die 2. Regel ist der Name. Die Datei muss mit lib anfangen und die Endung muss .so sein. Z.b. sagen wie mal, due erstellst eine Bibliothek, die mit -lmybib gelinkt werden soll, dann muss die Datei libmylib.so heißen. Diese muss sich in einer der verzeichnisse von LD_LIBRARY_PATH oder ld.so.conf. Bei einem gcc ··· -lmybib sucht der Linker in dieser Liste von Verzeichnisse nach der Datei libmybib.so und linkt sie (eigentlich ist ld, der danach sucht).
-
Aha, danke.
Und werden diese so-Dateien dann in die Binärdatei hineincompiliert oder müssen diese am Zielrechner installiert sein?
Unter Windows ist es ja so: Statische Bibliotheken (.lib) werden als ganzes reincompiliert.
Bei DLLs ist es hingegen so, dass es auch immer eine .lib gibt, die statisch mit-compiliert wird. Der eigentliche Code steht aber eben in der DLL, die installiert sein muss, damit das Programm läuft.
Wie ist das unter Linux? "Shared object" klingt für mich ja stark so als ob es immer vorhanden sein müsste (du hast ja auch gesagt dass das so was wie DLLs sind). Aber muss es nicht trotzdem immer auch einen (kleinen) statischen Teil geben? Immerhin muss ja Code compiliert werden, der dann zur Laufzeit den dynamischen Teil lädt. Wenn es rein dynamisch ist findet der Linker ja die Funktionsdefinitionen nicht. Unter Windows zumindest macht das eben die .lib.
mfg
-
Wenn du dynamisch linkst (also mit .so) dann müssen die .so Dateien auch im Zielrechnen sein, damit das Programm läuft.
-
Eigentlich alles, was man über Libraries wissen muss, findet man in der
Program-Library-HOWTO.