Page 1 of 1

execute fuer .so

Posted: 22. May 2001 15:20
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!

Re: execute fuer .so

Posted: 22. May 2001 16:04
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

Re: execute fuer .so

Posted: 22. May 2001 19:24
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

Re: execute fuer .so

Posted: 22. May 2001 19:25
by ronny
zu schnell gedrückt

Re: execute fuer .so

Posted: 23. May 2001 18:12
by cirad
Ah, danke. Das beantwortet mir fast alles Fragen! Nur eine noch. Was ist .a ???

Re: execute fuer .so

Posted: 28. May 2001 13:20
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.