View source for Dynamisk länkning och shared objects i FreeBSD

Detta ämne är under utveckling.

Problem med dynamisk länkning är ofta det som strular när man ska kompilera länka ihop något större program. Särskilt om man inte är root på systemet och måste installera sina program på andra ställen än systemets standardställen.


== Exempel: myapp & libfoo.so ==

Vi börjar med ett exempel på ett litet program som består av en exekverbar fil + en so-fil. Detta exempel kommer sedan användas för att åskådliggöra problemen runt so-filer och dynamisk länkning. Vår filstruktur i exemplet är:

<pre>
.
├── Makefile
├── lib
│   ├── Makefile
│   ├── foo.c
│   └── foo.h
└── main.c
</pre>

== Länka utan sökväg till runtime loadern ==

=== Bygga och länka libfoo.so ===
Källkoden till libfoo.so ligger i foo.c och dess interface i foo.h. När vi kompilerar koden måste vi använda -fPIC flaggan. Vi använder det fullständiga kommandot:
{{Box Kommando|Kompilera foo.c|
<pre>
gcc -std=c99 -Wall -Wextra -O2 -fPIC -c foo.c
</pre>
}}
För att sedan länka ihop libfoo.so så använder vi följande kommando:
{{Box Kommando|Länka libfoo.so|
<pre>
gcc -shared -o libfoo.so foo.o
</pre>}}
Optionen <tt>-shared</tt> används för att skapa ett shared object (so-fil).

=== Bygga och länka myapp ===
Vår exekverbar fil består av källkoden main.c men behöver en funktion i libfoo.so för att kunna köras. Vi kompilerar källkoden med kommandot:

{{Box Kommando|Kompilera main.c|
<pre>
gcc -std=c99 -Wall -Wextra -Wno-unused -O2 -Ilib -c main.c
</pre>}}

För att länka programmet myapp kör vi kommandot:
{{Box Kommando|Länka myapp|
<pre>
gcc -Llib -o myapp main.o -lfoo
</pre>}}

Om man nu försöker köra myapp kommer man få följande fel:
{{Box Kommando|./myapp|
<pre>
/libexec/ld-elf.so.1: Shared object "libfoo.so" not found, required by "myapp"
</pre>}}
När programmet myapp ska laddas hittar loadern inte libfoo.so filen. För att lösa problem kan vi sätta variabeln LD_LIBRARY_PATH och peka ut var vår libfoo.so ligger. Nu kommer loadern hitta libfoo.so och myapp går att köra. Denna lösning har dock många nackdelar.

== Länka med absolut eller relativ sökväg till runtime loadern ==
För att slippa behöva sätta LD_LIBRARY_PATH vid exekvering kan sökvägar byggas in i ELF filen vid länkning. Loadern kommer vid exekvering använda dessa för att hitta de dynamiskt länkade so-filerna. Bygg och länka libfoo.so som ovan, men länka myapp med följande kommando:
{{Box Kommando|Länka myapp med absolut sökväg till libfoo.so|
<pre>
gcc -Llib -Wl,-rpath,/<path>/lib -o myapp main.o -lfoo
</pre>}}
Vi kan nu köra myapp utan att behöva sätta LD_LIBRARY_PATH. Man kan kolla vilka sökvägar som är inbyggda i ELF-filen genom att köra kommandot:
{{Box Kommando|Lista runtime sökvägar i ELF-fil|
<pre>
readelf -Wa myapp | grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [/<path>/lib]
</pre>}}

Nackdelen med en absolutsökväg är att libfoo.so måste ligga på samma ställe överallt programmet myapp ska köra. Så en relativ sökväg kan tyckas vara bättre. Då behöver bara myapp och libfoo.so relativt ligga på samma ställe. Låt och ändra till en relativ sökväg genom att länka myapp med kommandot:
{{Box Kommando|Länka myapp med relativ sökväg till libfoo.so|
<pre>
gcc -Llib -Wl,-rpath,./lib -o myapp main.o -lfoo
</pre>}}

Vi kan nu köra myapp, men bara när vi står i samma katalog som myapp själv. Så relativ sökväg löser inte heller problemet att kunna köra myapp från olika ställen.

== Länka med sökväg via $ORIGIN till runtime loadern ==

[[Category:FreeBSD]]