execute fuer .so

Post Reply
Message
Author
cirad

execute fuer .so

#1 Post by cirad »

Warum sind .so-Files mit dem Executerecht versehen? Funktionieren tut auch alles ohne dieses Recht - scheint zumindest so. Warum muessen die also ausfuehrbar sein?

Und was ist der Unterschied zwischen .la und .so?

Schonmal Danke fuer Antworten!

Sebastian Ude

Re: execute fuer .so

#2 Post by Sebastian Ude »

.la-Dateien sind vom GNU libtool generierte Text-Dateien, die Informationen über die eigentliche Library enthalten (Abhängigkeiten usw.) und das Linken von Libraries mittels libtool erleichtern sollen.


Für weitere Informationen siehe:

http://www.gnu.org/software/libtool/manual.html

ronny
Posts: 313
Joined: 24. Apr 2001 11:11
Location: Muehlacker, BW

Re: execute fuer .so

#3 Post by ronny »

die .so files sind i.d.r. nur links auf datei mit versionsnummer z.b. .so.3.2
und symlinks haben immer alle bits gesetzt, da nur die rechte der verlinkten datei zählen

ronny
Posts: 313
Joined: 24. Apr 2001 11:11
Location: Muehlacker, BW

Re: execute fuer .so

#4 Post by ronny »

zu schnell gedrückt
Last edited by ronny on 22. May 2001 19:25, edited 1 time in total.

cirad

Re: execute fuer .so

#5 Post by cirad »

Ah, danke. Das beantwortet mir fast alles Fragen! Nur eine noch. Was ist .a ???

Sebastian Ude

Re: execute fuer .so

#6 Post by Sebastian Ude »

*.a sind statische Libraries.

Um mal ganz grob den Unterschied zwischen dynamischen und statischen Libraries zu erklären:

Wenn ein Programm gegen eine statische Library geladen wird, dann wird der Code aus der statischen Library (*.a-Datei) in das Programm hineinkopiert.

Das hat viele Nachteile:

- Die Binaries werden sehr gross
- Library-Code dupliziert sich in allen Binaries -> Speicherplatzverschwendung
- Nach einem Upgrade der Libraries müssen alle Applikationen neu gelinkt werden, um von der neuen Version der Library zu profitieren

Und es gibt noch viel mehr Nachteile.


Wird ein Programm allerdings gegen eine dynamische Library gelinkt (*.so), dann wird im Programmcode lediglich auf den Code in der Library verwiesen.
Der Code bleibt also (im Gegensatz zum statischen Linken) in der Library, und diese wird halt während der Runtime geladen.

Dadurch ergeben sich einige Vorteile:

- Binaries bleiben klein
- Kein uneffizient duplizierter Code
- Nach einem Update der Library nicht zwingend ein Neu-Linken der Applikation notwendig


In manchen Situationen macht es allerdings Sinn, eine Library statisch einzubinden.
Das ist zum Beispiel der Fall, wenn man nicht vorraussetzen möchte, dass auf dem System des Benutzers die dynamische Library vorhanden ist. Das muss nämlich bei Binaries, die dynamisch gegen eine Library gelinkt wurden der Fall sein.


Technisch gesehen ist eine *.a-Datei ein ar-Archiv, dass einzelne Objektdateien (*.o) sowie einen Index der in der Library vorhandenen Symbole (generiert mit ranlib oder der 's'-Option von ar - wird vom Linker benötigt) enthält.

Theoretisch könntest du eine statische Library (*.a-Datei) mit 'ar xv' entpacken und hättest dann die einzelnen Objektdateien, die du manuell verlinken könntest.

Post Reply