6 Wie eine dynamische Bibliothek gefunden wird

Wo nach einer dynamischen Bibliothek gesucht wird, ist zum einen interessant, um ein Programm überhaupt starten zu können, und zum anderen wirkt sich die Suchreihenfolge darauf aus, welche Bibliothek verwendet wird, wenn mehrere Versionen mit dem selben Namen existieren.

Wenn beim Laden der Bibliothek der volle Pfadname angegeben wird, dann ist die Sache klar.

Ansonsten gilt:

Unter Linux wird zum Auflösen externer Referenzen das Programm ld.so verwendet, welches nach Bibliotheken in folgender Reihenfolge sucht (aus [Systemzentrale]):

Der interne Cache für die Bibliotheken wird vom Programm ldconfig aktualisiert. ldconfig liest aus /etc/ld.so.conf eine Liste von Verzeichnissen, sucht in allen diesen Verzeichnissen nach shared objects, und trägt diese dann in den internen Cache ein. ldconfig kann üblicherweise nur als Benutzer root gestartet werden.

Unter Windows wird nach einer DLL zuerst im Verzeichnis gesucht, aus dem die zugehörige EXE gestartet wurde, dann in den Verzeichnissen der PATH-Variable.

Soweit das von Microsoft dokumentierte Verhalten. Zudem kommt es aber manchmal vor, daß eine Bibliothek nicht erneut geladen wird, wenn ein anderes Programm eine DLL gleichen Namens bereits in den Speicher gebracht hat. Dann hängt das Verhalten des neu gestarteten Programms (nämlich welche DLL verwendet wird) davon ab, welche anderen Programme bereits laufen. Wenn das mal gut geht...(siehe dazu auch Versionen einer dynamischen Bibliothek). Wie einheitlich sich hier die verschiedenen Windowsversionen verhalten, weiß ich nicht.

Konkretes Beispiel: Ein Küchenhersteller hatte unter Windows NT ein Serverprogramm, welches eine Kommunikation zwischen einer grafischen Auftragserfassung in AutoCAD einerseits und einer Warenwirtschaft auf einem Unixrechner andererseits realisiert. Das Serverprogramm benötigt natürlich die Datei wsock32.dll, in der die Funktionen zur Socketprogrammierung liegen.

Soweit funktioniert alles meistens prima, nur manchmal kann das Serverprogramm keine Verbindung zum Unixrechner aufbauen. Als Ursache stellte sich nun heraus, daß manchmal auch die BTX-Software von T-Online lief, die eine eigene Version der DLL lädt, und das Serverprogramm genau dann nicht mehr läuft, wenn es hinterher gestartet wird: es verwendet dann die DLL, die von T-Online mitgeliefert wird, und die hat nun leider irgendwo ein paar Fehler. Solche Abhängigkeiten zu finden ist reine Glückssache.

www.wachtler.de