Re: Linker-Problem mit Port

Nur eine kleine Ergänzung ...

Sascha Hüdepohl wrote:
 > # ld -lsqlite3 --verbose:
 > ...
 > ld: cannot find -lsqlite3
 > 
 > ld guckt nicht in `/usr/local/lib`?
 > 
 > Aber:
 > 
 > # ldconfig -r | grep lsqli
 >         140:-lsqlite3.0 => /usr/local/lib/libsqlite3.so.0
 > 
 > gefunden wird es eigentlich.

Das sind zwei verschiedene Dinge:

Der Linker ld liest Objekt-Dateien (*.o), die der Compiler
aus dem Quellcode generiert, sowie statische Libraries (*.a,
die im Grunde genommen auch nur *.o-Dateien sind, die in
einem Archiv zusammengefasst sind) und backt sie zu einem
Binary zusammen.  Außerdem schaut er sich die dynamischen
Libraries (*.so = „shared object“) an und speichert Referenzen
darauf im Binary.  Der Linker ld schaut tatsächlich per
Default _nicht_ in /usr/local, wie Harold schon schrieb.
Man muss ihm das ausdrücklich mitteilen.

ldconfig dagegen verwaltet den Shared-Library-Cache für den
Laufzeit-Linker, siehe die Manual-Page rtld(1).  Das klingt
erstmal ähnlich (beides ist irgendwas mit „Linker“), hat
aber eine ganz andere Aufgabe:  Der Runtime-Linker sorgt
dafür, dass das Binary und alle dynamischen Libraries, die
es benötigt, in den Speicher geladen werden, und erzeugt
daraus den eigentlichen lauffähigen Prozess.  Wo dabei die
Libraries gesucht werden, kann auf verschiedene Arten
festgelegt werden, unter anderem mit ldconfig, und dies
ist per Default auch auf /usr/local/lib konfiguriert;
siehe „ldconfig_paths“ in /etc/defaults/rc.conf.

Zusammengefasst:  ld wird beim Compilieren / Bauen benötigt,
um ein ausführbares Binary zu erzeugen.  ldconfig + rtld wird
erst beim Ausführen des Binaries benötigt, um die dynamischen
Libraries in den Speicher zu laden.

Ich hoffe, ich konnte damit ein paar Klarheiten beseitigen.  ;-)

Gruß
 ― Olli

PS:  Das war etwas vereinfacht ausgedrückt.  Korrekterweise
lädt der Runtime-Linker nichts in den Speicher – er legt
lediglich Memory-Mappings an.  Das Laden in den Speicher
(sofern überhaupt notwendig) übernimmt der Kernel.  Wenn ein
Binary z.B. mehrmals gleichzeitig ausgeführt wird (also in
verschiedenen Prozessen), dann befindet sich der Code nur
einmal im Speicher.  Ebenso der Code von Shared-Libraries,
die von mehreren unterschiedlichen Prozessen benutzt werden
(das können auch Prozesse von unterschiedlichen Binaries
sein).  Dies fällt in die Zuständigkeit des VM-Subsystems
des Kernels.


-- 
Oliver Fromme, München   --   FreeBSD + DragonFly BSD

``We are all but compressed light'' - Albert Einstein


To Unsubscribe: send mail to [email protected]
with "unsubscribe de-bsd-questions" in the body of the message