Librarys, Plugins, Modules, ...?
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.
Re: Librarys, Plugins, Modules, ...?
Zitat:
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
Zitat:
Wie kann man so ein .a-Archiv beim Kompilieren benutzen - mit "-lname" (wobei name zwischen "lib" und ".a" steht)?
Ja
Zitat:
Wie kann man .a-Dateien erstellen?
man ar
Zitat:
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.
Zitat:
Wie kann man die .so-Dateien benutzen - auch so, wie ich bei .a-Dateien denke?
Ja
Zitat:
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.
Zitat:
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.
Zitat:
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.
Zitat:
Wie erstellt man Plug-Ins / Modules?
Die Shared libs
Ciao,
_
Re: Librarys, Plugins, Modules, ...?
Zitat:
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ä
Re: Re: Librarys, Plugins, Modules, ...?
Zitat:
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.../autoconf.html
http://www.gnu.org/software/automake.../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
Re: Motiviert für ein Howto
Zitat:
Original geschrieben von RapidMax
Jetzt habt ihr mich gleich dazu motiviert ein Howto zu schreiben: GNU Autoconf, Automake und Libtool.
Cool! Klasse Idee!
Ciao,
_
Re: Motiviert für ein Howto
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.
Re: Re: Motiviert für ein Howto
Zitat:
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 :)
Zitat:
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.
Zitat:
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.
Zitat:
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,
_