Librarys, Plugins, Modules, ...?

[Firebird]

Ich hab ein paar Fragen bzgl. diesen ganzen Dateitypen die auf .so/.o enden...

Werden die .o-Dateien in einem .a-Archiv während des Kompilierens direkt vom Linker da mit in die ausführbare Datei getan, wie die .o-Dateien die der Compiler erst erstellt?
Wie kann man so ein .a-Archiv beim Kompilieren benutzen - mit "-lname" (wobei name zwischen "lib" und ".a" steht)?
Wie kann man .a-Dateien erstellen?

Sind .so-Dateien (Bibliotheken, nicht Plug-Ins und was sonst noch so endet) sowas wie .a-Dateien, nur dass sie schon gelinkt sind, und dass sie wenn sie von einer Anwendung benutzt werden, nicht beim kompilieren mit reingepackt werden, sondern erst beim ausführen benutzt werden?
Wie kann man die .so-Dateien benutzen - auch so, wie ich bei .a-Dateien denke?
Wie kann man .so-Dateien erstellen?

Sind Plug-Ins und Modules das gleiche?
Wie benutzt man Plug-Ins / Modules in seiner Anwendung?
Wie erstellt man Plug-Ins / Modules?

Ich hoffe mal, dass mir irgendjemand ein paar Fragen beantworten, oder eine Seite geben kann, wo dass gut erklärt wird. Ohne diese ganzen Sachen scheint man nämlich beim Programmieren nicht grad so weit zu kommen.

[anda_skoa]

Original geschrieben von Firebird
Werden die .o-Dateien in einem .a-Archiv während des Kompilierens direkt vom Linker da mit in die ausführbare Datei getan, wie die .o-Dateien die der Compiler erst erstellt?

Ja



Wie kann man so ein .a-Archiv beim Kompilieren benutzen - mit "-lname" (wobei name zwischen "lib" und ".a" steht)?

Ja



Wie kann man .a-Dateien erstellen?

man ar



Sind .so-Dateien (Bibliotheken, nicht Plug-Ins und was sonst noch so endet) sowas wie .a-Dateien, nur dass sie schon gelinkt sind, und dass sie wenn sie von einer Anwendung benutzt werden, nicht beim kompilieren mit reingepackt werden, sondern erst beim ausführen benutzt werden?

Mehr oder weniger, d.h.das Auflösen der Symbole, also das Linken, wird erst zur Laufzeit von einem Runtimelinker gemacht.
Die interne Struktur ist anders als bei einem .a Archiv und die Objectfile müssen mit bestimmten Parametern kompiliert worden sein, um ihre Symbole erst später an Programmadressen zu binden.



Wie kann man die .so-Dateien benutzen - auch so, wie ich bei .a-Dateien denke?

Ja



Wie kann man .so-Dateien erstellen?

Hmm, da bin ich mir nicht sicher.
Ich glaube die einzelenen Objects müssen mit -fpic -fPIC kompiliert werden und die resultierende Lib mit -shared gelinkt werden.



Sind Plug-Ins und Modules das gleiche?

Modules kann vieles sein, in diesem Zusammenhang vielleicht eine funktionale Untereinheit.
Ein Plugin wäre dann ein Module, aber ein Module wäre nicht unbedingt ein Plugin.



Wie benutzt man Plug-Ins / Modules in seiner Anwendung?

Ein Plugin ist eigentlich nur eine normale Shared Library (.so), nur dass sie nicht beim Komilieren der Applikation angegeben wird.
Das Programm öffnet die Library Datei mit dlopen und sucht dann eines oder mehrere Funktionssymbole mit dlsym, bindet die an lokale Funktionspoint und ruft sie dann auf.



Wie erstellt man Plug-Ins / Modules?

Die Shared libs

Ciao,
_

[RapidMax]

Mit Hilfe von Libtool kann eine Bibliothek erzeugt werden, ohne sich um die jeweiligen Interna der entsprechenden Plattform zu kümmern und um frei wählen zu können, ob statische linkbare Bibliotheken (.a) oder dynamsch linkbare (.so) erzeugt werden, bzw. ob statisch oder dynamisch gegen die Bibliothek gelinkt werden soll.

Um Beispielsweise ein statische Bibliothek zu erzeugen, wird anstelle von:

$ gcc -o test.o test.c
$ ar cru libtest.a test.o

$ libtool gcc -c test.c
$ libtool gcc -rpath /usr/local/lib -o libtest.la test.lo

Natürlich verwendet man libtool in der Regel in Kombination mit automake.

Gruss, Andy

[Firebird]

THX für die Antworten :)

Gibt es für libtool und automake (und autoconf) etc. mal irgendwelche erklärungen?
Manuals dafür existieren bei mir leider net, und die versteh ich eh meistens net :(

[peschmae]

Original geschrieben von Firebird
Wie kann man so ein .a-Archiv beim Kompilieren benutzen - mit "-lname" (wobei name zwischen "lib" und ".a" steht)?


so, oder auch in dem du das .a-Archiv irgendwo unter all die .o-Objektdateien mixt, etwa so:
gcc -o testerl testerl.o testerl-objektarchiv.a

Zu automake und autoconf such ich auch schon lange was vernünftiges. (Nicht ein 1-te 2 Schritte Tutorial und auch nicht eine Referenz für die dies eh schon können, sondern was für die dies noch nicht können, damit sies nacher können :))

MfG Peschmä

[RapidMax]

Original geschrieben von peschmae
Zu automake und autoconf such ich auch schon lange was vernünftiges. (Nicht ein 1-te 2 Schritte Tutorial und auch nicht eine Referenz für die dies eh schon können, sondern was für die dies noch nicht können, damit sies nacher können :))

Da wäre mal die Dokumentation:
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/autoconf.html
http://www.gnu.org/software/automake/manual/automake.html

Ich habe mir jedoch "GNU Autoconf, Automake, and Libtool" von Gary V. Vaughan zugelegt, das ich weiterempfehlen kann. Es zeigt gut, wie sich die Tools einsetzen lassen, ohne dass der Inhalt allzuschnell veraltet, da viel Wert darauf gelegt wird die Konzepte zu erklären und die technischen Details der offiziellen Dokumentation überlassen werden.

Gruss, Andy

[axeljaeger]

Ich will jetzt keinen Glaubenskrieg vom Zaun brechen, naja, eigentlich schon: Muss das sein, das man ein Handbuch zur Benutzung eines Buildsystemes braucht? Sollte ein Programmierer nicht lieber sein Programm schreiben, als Skripte für das Buildsystem?

[RapidMax]

Die Tools haben eine gewisse Einstiegs-Hürde. Und zwar besteht die darin, das Konzept zu verstehen. Ist das einmal klar, kann mit ein paar wenigen Zeilen ein komplettes Buildsystem erstellt werden, das lokal prima funktioniert.

In Teams muss nur ein Entwickler sich damit beschäftigen. Der Rest kümmert sich nur um die Makefiles.am, um ihre neu erstellen Source darin aufzunehmen. Und die Syntax der Makefiles.am ist definitiv einfacher als die von Makefiles und vor allem schneller geschrieben und übersichtlicher.

Ein wichtiges Ziel von automake/autoconf/libtool ist die Portierbarkeit der Software und damit Source-Code kompatibilität auch dort, wo es Unterschiede gibt. Erst wenn wirklick portable Programme entwickelt werden sollen, wird es kompliziert. Hier müssen die Unterschiede der einzelnen Systeme erfasst werden und z.T. mit eigenen M4 Makros und portablem Bash-Script getestet und Massnahmen getroffen werden.

Gruss, Andy

[RapidMax]

Jetzt habt ihr mich gleich dazu motiviert ein Howto zu schreiben: GNU Autoconf, Automake und Libtool (http://www.mrunix.de/forums/showthread.php?s=&postid=148924#post148924).

Gruss, Andy

[anda_skoa]

Original geschrieben von RapidMax
Jetzt habt ihr mich gleich dazu motiviert ein Howto zu schreiben: GNU Autoconf, Automake und Libtool.


Cool! Klasse Idee!


Ciao,
_

[axeljaeger]

Original geschrieben von RapidMax
Jetzt habt ihr mich gleich dazu motiviert ein Howto zu schreiben: GNU Autoconf, Automake und Libtool (http://www.mrunix.de/forums/showthread.php?s=&postid=148924#post148924).


Das ist sehr löblich, trotzdem bin ich schon vor einiger Zeit nach einigem Herumprobieren wieder von Autoconf zurück zu qmake gekommen. Mich stört ein bißchen an dem System, das wenn man z.B. die Buildscripts für ein KDE-Programm nimmt, nicht weniger als 1.9 MB an Skripten mitzuliefern sind. Da werden dann bei configure Sachen getestet, die ich gar nicht wissen will (size of in, size of long). Es wäre schön, wenn mit diesem System portable Tarballs möglich wären, leider musste ich feststellen, das die Tarballs nichtmal für alle Linuxsysteme geeignet sind KDE Programme auf Mandrake), weil da KDE in /usr/ liegt. Anscheinend ist das sehr schwierig, in ein configure.in eine einfache Abfrage mittels kde-config einzubauen.

[RapidMax]

Ich habe die Scripte angeschaut, die KDevelop bei einem neuen Projekt erstellt. Diese sind natürlich sehr universell gehalten und testen auch Dinge, welche gar nicht notwendig sind. Und die KDE Scripte zu erweitern ist nicht ganz einfach, da man erst mal durchblicken muss. Teilweise werden die Konfigurations-Dateien doppelt durch den Makroprozessor gelassen (.in.in), was die Übersichtlichkeit nicht gerade verbessert. Und ich nehme an, dass das nur auf die Systeme portierbar ist, für welche auch QT und KDE verfügbar sind.

Ich kann jetzt schlecht abschätzen, mit was für einem Aufwand ein eigenes Script zu bauen ist, da ich mich nicht mit QT/KDE auskenne. Ich denke wenn es gut auf das eigene Programm zugeschnitten ist, dann wird es auch kleiner.

Ich sehe kein grosses Problem, kde-config abzufragen. Ich würde ein Makro in die acinclude.m4 einbauen, welches in der configure.in aufgerufen wird. Zuerst testet man ob kde-config überhaupt da ist, dann werden die Optionen ausgelesen (flags hinzufügen, prefix neu setzen etc.).
Das Problem ist nur der Aufwand. Ev. kann man sich bei bestehenden Programmen bedienen.

Gruss, Andy

[anda_skoa]

Original geschrieben von axeljaeger
nicht weniger als 1.9 MB an Skripten mitzuliefern sind.

Man sollte wirklich von den Distributoren erwarten, dass sie ein entsprechendes admin Verzeichnis zum Beispiel im kdelibs-devel Paket mitliefern könnten.
Vielleicht wäre das mal ein Feature Request :)



Da werden dann bei configure Sachen getestet, die ich gar nicht wissen will (size of in, size of long).

Möglicherweise braucht man das auf nicht-32bit Plattformen.
Oder es ist schwierig eigene Checks einzubauen und das Standard Skript hat die häufigst gebrauchten einfach dabei.



Es wäre schön, wenn mit diesem System portable Tarballs möglich wären, leider musste ich feststellen, das die Tarballs nichtmal für alle Linuxsysteme geeignet sind KDE Programme auf Mandrake), weil da KDE in /usr/ liegt.

An /usr kanns nicht liegen, das ist hier auf Debian auch so und da läufts.



Anscheinend ist das sehr schwierig, in ein configure.in eine einfache Abfrage mittels kde-config einzubauen.

Möglicherweise ist es einfach das Standard Script von KDE, da geht das natürlich schwer, da ja hier potentiell kde-config noch nicht vorhanden ist.

KDevelop sollte da aber schon ein verändertes verwenden, da hast du schon Recht.

Ciao,
_