fragen zu libs und SOs

loki1985

hi folks!

ich habe mal ein paar grundlegende fragen.
wäre super wenn mir jemand da antworten zu hätte...

1. gibt es einen unterschied zwischen libraries mit der endung .a/.lib/.la ?
2. sind alle (statischen) libraries platform-dependant ?

3. kann man eine .so in linux genauso mitliefern wie eine DLL in windows, also einfach im ordner der binary? und wenn, gibt es so eine fallback-regel wie in Windows á la erst im CWD suchen, und dann im path ?

/EDIT: ach ja, und um zu rechtfertigen, wieso das hier im ANCI C forum ist: alles aus dem blickwinkel eines C-coders, und: gibt es C-libs und C++-libs?

merci,

---loki

groovemaster

loki1985 schrieb:

1. gibt es einen unterschied zwischen libraries mit der endung .a/.lib/.la ?

Ich kenn zwar .la nicht, aber zwischen .a und .lib gibt es einen Unterschied.

loki1985

groovemaster schrieb:

Ich kenn zwar .la nicht, aber zwischen .a und .lib gibt es einen Unterschied.

und der wäre?

groovemaster

Implementationsspezifisch. MinGW spuckt zB .a Libs im coff Format aus, Microsoft hat da afaik ein eigenes win32 Format für seine .lib Dateien.

1. .la und .a haben nichts miteinander zu tun, vielmehr ist .la eine Art Add-on zu .so. Es handelt sich dabei um Textdateien, also kannst du ruhig einach mal nen Blick reinwerfen. Im Wesentlichen beeinflusst eine solche Datei das Verhalten von dlopen - die häufigste Anwendung dürfte das automatische Auflösen von Abhängigkeiten sein.

.so ist eine gängige Endung für dynamisch linkbare Libraries unter Linux und manchen UNIX-Derivaten, .a ist eine statische Library. Das ist im Wesentlichen ein ar-Archiv, das die Objektdateien enthält, aus denen die Library zusammengesetzt ist. Geh doch mal auf die Konsole und führ

ar t /usr/lib/libz.a

aus.

2. Diese Libraries enthalten alle nativen Code und sind dementsprechend plattformabhängig.

3. Der Linker sucht seine Libraries in den Verzeichnissen, die in den Umgebungsvariablen LD_RUN_PATH und LD_LIBRARY_PATH eingetragen sind. Wenn er sie da nicht findet, sucht er in vorher einkompilierten Standardverzeichnissen; idR sind das /lib und /usr/lib, und wenn er sie da auch nicht findet, sucht er in den Verzeichnissen, die in der /etc/ld.so.conf aufgelistet sind.

Es ist natürlich möglich, ein Programm samt libraries in das selbe Verzeichnis zu legen, und es ist für manche Programme gar nicht mal so unüblich, insbesondere, wenn man es nachher chrooten will. Allerdings muss man dem Linker sagen, dass er dieses Verzeichnis auch nach libaries durchsuchen soll - entweder schreibt man das Verzeichnis dazu in die /etc/ld.so.conf, oder man schreibt sich ein kleines Starter-Skript, das anstelle des eigentlichen Programms ausgeführt wird und den Pfad in LD_RUN_PATH oder LD_LIBRARY_PATH aufnimmt, zum Beispiel

#!/bin/sh

LD_RUN_PATH=$(dirname $0):$LD_RUN_PATH $(dirname $0)/programm

Oh, und ja, es gibt C++-Libraries.

loki1985

danke leuts, das hat meine fragen so ziemlich beantwortet...

nur eins noch: ich hab bisher mit linux fast noch nix gemahcht, daher nochmal ganz simpel gefragt: ist es machbar, eine binary direkt zusammen mit einer .SO auszuliefern, sodass das programm läuft, egal ob der user diese .SO bereits hat (auch wenn andere version), und der user selbst muss dafür nichts umstellen/seine systemconfig wird nicht manipuliert?
die sache mit dem script denke ich mal löst das, aber modifiziert sie auch nichts?

Das Skript modifiziert nichts, nein. Es ruft ja auch nur das Programm mit einer leicht veränderten Umgebung auf (LD_RUN_PATH verändert halt). Nimm zum Beispiel an, du hast das Programm und die Libraries in /opt/programm liegen, dann macht das Skript im Grunde das selbe wie

LD_RUN_PATH=/opt/programm:$LD_RUN_PATH /opt/programm/programm

...mit anderen Worten, es ruft /opt/programm/programm in einer Umgebung auf, in der LD_RUN_PATH um /opt/programm erweitert wurde, so dass der Linker die Libraries findet.