Wie werden dyn. Libraries eingebunden?

[Monk (roehrmond)]

Wenn ich ein Programm starte das von dynamischen Bibliotheken abhängt 
(*.dll bzw *.so), wer findet diese Dateien und lädt sie in den Speicher? 
Der Betriebssystem-Kern, das Anwendungsprogramm selbst oder ist da noch 
eine Instanz zwischen?

Das interessiert mich für Linux und Windows.

[Klaus W. (mfgkw)]

Unter Linux ist das Stichwort ld.so bzw. ld-linux.so.

[Gerald K. (geku)]

Klaus W. schrieb:
> Unter Linux ist das Stichwort ld.so bzw. ld-linux.so.

Aber wer lädt die SO-Dateien in den Arbeitspeiche?

Das Programm selbst, wenn dieses die dyn. Library benötigt?

[C-hater (c-hater)]

Steve van de Grens schrieb:

> Wenn ich ein Programm starte das von dynamischen Bibliotheken abhängt
> (*.dll bzw *.so), wer findet diese Dateien und lädt sie in den Speicher?
> Der Betriebssystem-Kern, das Anwendungsprogramm selbst oder ist da noch
> eine Instanz zwischen?
>
> Das interessiert mich für Linux und Windows.

Also bei Windows ist das so:

Es gibt zwei verschiedene Möglichkeiten, eine DLL einzubinden, nämlich 
"quasi-statisch" und wirklich "dynamisch". Davon hängt ab, was genau die 
DLL lädt. Im ersteren Fall macht's der Exe-Loader des OS, im zweiten 
Fall muss es die Anwendung zu Fuss selber erledigen.

Letztlich greifen aber beide Varianten natürlich wiederum auf Routinen 
zurück, die das OS bereitstellt.

Warum schnappst du dir nicht einfach einen brauchbaren Debugger und 
spielst das selber durch? Da kannst du dir im Detail anschauen, was da 
passiert. Brauchst nur eine wenig Ausdauer. ;o)

[Gerald K. (geku)]

C-hater schrieb:
> Warum schnappst du dir nicht einfach einen brauchbaren Debugger und
> spielst das selber durch? Da kannst du dir im Detail anschauen, was da
> passiert. Brauchst nur eine wenig Ausdauer. ;o)
Auf 
https://learn.microsoft.com/de-de/sysinternals/downloads/sysinternals-suite 
gibt es die dafür notwenigen Tools.

[Foobar (asdfasd)]

Linux unterstützt mehrere Dateiformate (/usr/src/linux/fs/binfmt_xxx.c). 
Bei ELF-Dateien wird die Datei vom Kernel in den Speicher geladen.  Im 
Header der Datei steht ein "Interpreter" (objdump -sj.interp /bin/echo, 
normalerweise "ld-linux.so.X", ein statisches Library).  Dieser 
"Interpreter" wird auch noch geladen und dann gestartet (nicht das 
Programm selbst).  Der kümmert sich dann um den Rest (man ld.so). 
Dessen Arbeit kann man mit "strace /bin/echo" beobachten.  Das Laden der 
abhängigen Libraries findet also außerhalb des Kernels statt.

Dieser Loader steht der Anwendung selbst auch zur Verfügung (man 
dlopen).  Damit kann man bei Bedarf weitere Libraries nachladen 
(Beispiel in der man-page).

[Rolf M. (rmagnus)]

Foobar schrieb:
> Dieser "Interpreter" wird auch noch geladen und dann gestartet (nicht das
> Programm selbst).

Den kann man übrigens auch manuell aufrufen:

$ /lib64/ld-linux-x86-64.so.2 --help
Usage: /lib64/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked 'ld.so', the program interpreter for dynamically-linked
ELF programs.  Usually, the program interpreter is invoked automatically
when a dynamically-linked executable is started.

You may invoke the program interpreter program directly from the command
line to load and run an ELF executable file; this is like executing that
file itself, but always uses the program interpreter you invoked,
instead of the program interpreter specified in the executable file you
run.  Invoking the program interpreter directly provides access to
additional diagnostics, and changing the dynamic linker behavior without
setting environment variables (which would be inherited by subprocesses).

  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
                        object we can handle
  --inhibit-cache       Do not use /etc/ld.so.cache
  --library-path PATH   use given PATH instead of content of the environment
                        variable LD_LIBRARY_PATH
  --glibc-hwcaps-prepend LIST
                        search glibc-hwcaps subdirectories in LIST
  --glibc-hwcaps-mask LIST
                        only search built-in subdirectories if in LIST
  --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names
                        in LIST
  --audit LIST          use objects named in LIST as auditors
  --preload LIST        preload objects named in LIST
  --argv0 STRING        set argv[0] to STRING before running
  --list-tunables       list all tunables with minimum and maximum values
  --list-diagnostics    list diagnostics information
  --help                display this help and exit
  --version             output version information and exit

This program interpreter self-identifies as: /lib64/ld-linux-x86-64.so.2

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /lib/x86_64-linux-gnu (system search path)
  /usr/lib/x86_64-linux-gnu (system search path)
  /lib (system search path)
  /usr/lib (system search path)

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

Legacy HWCAP subdirectories under library search path directories:
  haswell (AT_PLATFORM; supported, searched)
  tls (supported, searched)
  avx512_1
  x86_64 (supported, searched)

[Gerald K. (geku)]

Mit der Funktion **dlopen**() kann vom Programm aus eine dynamische 
Library geladen werden.

https://man7.org/linux/man-pages/man3/dlopen.3.html

Codebeispiel:

#include <stdio.h>
#include <dlfcn.h>

int main() {
    void *library_handle;
    int (*add)(int, int);
    int (*subtract)(int, int);

    // Dynamische Bibliothek laden
    library_handle = dlopen("./libmath.so", RTLD_LAZY);
    if (!library_handle) {
        fprintf(stderr, "Fehler beim Laden der Bibliothek: %s\n", dlerror());
        return 1;
    }

    // Symbole auflösen
    add = dlsym(library_handle, "add");
    subtract = dlsym(library_handle, "subtract");
    if (!add || !subtract) {
        fprintf(stderr, "Fehler beim Auflösen der Symbole: %s\n", dlerror());
        dlclose(library_handle);
        return 1;
    }

    // Funktionen aufrufen
    int result = add(5, 3);
    printf("Ergebnis der Addition: %d\n", result);

    result = subtract(10, 4);
    printf("Ergebnis der Subtraktion: %d\n", result);

    // Dynamische Bibliothek entladen
    dlclose(library_handle);

    return 0;
}

[Monk (roehrmond)]

Dankeschön. So detaillierte Antworten hatte ich gar nicht erwartet.

[Harald K. (kirnbichler)]

Der Vollständigkeit halber:

Unter Windows werden DLLs, die als Importreferenzen im Programmheader 
des *.exe-Files aufgelistet werden, vom zum Betriebssystem gehörenden 
Programmlader geladen. Das ist das, was "c-hater" als "quasi-statisch" 
bezeichnet hat. Im Programmheader stehen die zu verwendenden DLLs und 
die daraus zu verwendenen Funktionen ("Prozedureinsprungspunkte" im 
schönen Microsoft-Deutsch). Wird so eine DLL nicht gefunden oder wird 
eine Funktion in der referenzierten DLLs nicht gefunden, gibt es eine 
allseits bekannte und verhasste Fehlermeldung.

Erst wenn alle im Programmheader aufgelisteten Referenzen aufgelöst 
werden können, wird der eigentliche Programmcode ausgeführt.

Mit Tools wie dem zu manchen Compilern gehörendenden "dumpbin" lassen 
sich die Importreferenzen auflisten, der "dependency walker" zeigt auch 
noch Abhängigkeiten von DLLs untereinander auf.


Die Bezeichnung "quasi-statisch", die "c-hater" verwendete, rührt daher, 
daß Programme, die ihre DLL-Referenzen vom Programmlader aufgelöst haben 
möchten, so geschrieben werden, als würden sie herkömmliche statische 
Libraries verwenden. Beim Linken aber werden dem Programm sogenannte 
"import-Libraries" untergeschoben, die dafür sorgen, daß die verwendeten 
Symbole als Importreferenzen im Programmheader eingetragen werden.


Der Gegenentwurf ist dynamisches Laden unter Kontrolle des bereits 
laufenden Programmes, das erfolgt mit der Win32-Funktion LoadLibrary. 
Zum Bestimmen von Funktionspointern dient die Win32-Funktion 
GetProcAddress.

Damit lassen sich Funktionalitäten wie "Plugins" realisieren, d.h. zur 
Laufzeit (und nur bei Vorhandensein) geladener Code, der ein Programm 
erweitern kann, aber nicht muss.

Das von Rolf beschriebene Verfahren mit ld.so entstammt in seinen 
Ursprüngen SunOS 4.0 (1988), und ist damit ähnlich alt wie das unter 
Windows verwendete Verfahren, das seine Wurzeln tief in den 
16-Bit-Zeiten noch vor Windows 3.x hat. SunOS war schon immer ein 
32-Bit-System, und konnte daher auf mehr und leistungsfähigere 
Ressourcen zurückgreifen als das ursprünglich 16-bittige Windows, das 
bis einschließlich Version 3.0 auf 8088-Systemen wie dem IBM PC/XT 
laufen konnte, d.h. mit gerade mal 640 kiB RAM ... Das erklärt die 
unterschiedlich flexiblen Ansätze des Programmladers.

[Oliver S. (oliverso)]

Harald K. schrieb:
> Der Vollständigkeit halber:

Der weiteren Vollständigkeit halber:

Auch unter Windows lassen sich dll's zur Laufzeit laden. Der Ablauf 
entspricht dabei im Prinzip dem von Linux: dll laden, Symbol auflösen, 
benutzen, wenn nicht mehr gebraucht, alles wieder schließen (und 
unloaden), fertig.

Oliver

[Hmmm (hmmm)]

Oliver S. schrieb:
> Der weiteren Vollständigkeit halber:
>
> Auch unter Windows lassen sich dll's zur Laufzeit laden.

Das hat er doch bereits sehr konkret beschrieben:

Harald K. schrieb:
> Der Gegenentwurf ist dynamisches Laden unter Kontrolle des bereits
> laufenden Programmes, das erfolgt mit der Win32-Funktion LoadLibrary.
> Zum Bestimmen von Funktionspointern dient die Win32-Funktion
> GetProcAddress.