execute fuer .so

Antworten
Nachricht
Autor
cirad

execute fuer .so

#1 Beitrag von cirad » 22. Mai 2001 15:20

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 Beitrag von Sebastian Ude » 22. Mai 2001 16:04

.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
Beiträge: 313
Registriert: 24. Apr 2001 11:11
Wohnort: Muehlacker, BW

Re: execute fuer .so

#3 Beitrag von ronny » 22. Mai 2001 19:24

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
Beiträge: 313
Registriert: 24. Apr 2001 11:11
Wohnort: Muehlacker, BW

Re: execute fuer .so

#4 Beitrag von ronny » 22. Mai 2001 19:25

zu schnell gedrückt
Zuletzt geändert von ronny am 22. Mai 2001 19:25, insgesamt 1-mal geändert.

cirad

Re: execute fuer .so

#5 Beitrag von cirad » 23. Mai 2001 18:12

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

Sebastian Ude

Re: execute fuer .so

#6 Beitrag von Sebastian Ude » 28. Mai 2001 13:20

*.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.

Antworten