Kompilierungsmethoden für Programme

[garibaldi]

Hi Leute!

Vorweg: Ich bin ein Neuling in Sachen Kompilieren und etwas verwirrt von den verschiedenen Möglichkeiten, ein bestimmtes Programm aus den Quellen zu kompilieren.

Ein Verzeichnis ~/src habe ich mir angelegt, in welchem ich die Quellen für das zu kompilierende Programm abgelegt werden. Sodann habe ich drei Methoden gefunden, um die Quellen für mich nutzbar zu machen:

1. Die klassische Methode mit

   Code: Alles auswählen

   $ ./configure 
   $ make
   # make install

2. Mit fakeroot:
   1. dsc, diff.gu orig.tar.gz runterladen
   2. dpkg-source -x PROGRAMM
   3. cd PROGRAMM
   4. fakeroot debian/rules binary
3. Mit dpkg-buildpackage[1]:
   1. dsc, diff.gu orig.tar.gz runterladen
   2. dpkg-source -x PROGRAMM
   3. cd PROGRAMM
   4. dpkg-buildpackage -us -uc

Nun meine Fragen:

1. Hat Methode a) einen Vorteil den anderen genüber?
2. Was machen b) und c) anders?
3. Wohin mit den .debs aus b) und c)?
4. Wo gibt's 'nen hilfreichen link zu diesem Thema?

TIA, garibaldi

[Aresius]

Da ist ein wenig was durcheinander:

Dein a. ist der letzte Schritt in einer Installation mit den GNU autotools [1]. Dieser Weg funktioniert bei allen Source-Paketen die ihn zur Verfügung stellen. Dabei passt ./configure das Makefile auf Dein System an indem es benötigte Bibliotheken findet usw. Du kannst ihm meist eine Reihe von Optionen übergeben um Teile des Programms mit zu bauen oder um anzugeben wohin die Binaries mit 'make install' installiert werden sollen. 'make' baut dann das Ganze und 'make install' installiert es.
Der Vorteil: das Ganze ist vollkommen Distributionsunabhängig
Der Nachteil: das Packagemanagement bekommt nichts davon mit, evtl kannst Du das Ganze nichtmehr sauber aus dem System entfernen oder Du beeinträchtigst die Funktion andere Software

Die beiden Wege b und c sind eigentlich identisch, 'dpkg-buildpackage' führt 'debian/rules' aus. Du erzeugst so Debian Pakete die Du hinterher mittels dpkg oder besser APT installieren kannst.
Vorteil: Die Software wird unter Debian perfekt in das System eingebunden (sofern die Pakete gut vorbereitet sind.
Nachteil: Das Ganze geht nur, wenn Du für Debian vorbereitete Source-Pakete hast. Hast Du das nicht, musst du es selbst machen, siehe dazu [2] und das Paket debhelper mit seiner Dokumentation.

Generell nutzen die Methoden b und c falls verfügbar die Methode a intern, nur bauen sie dann ein Paket daraus um die Installation im System über das Debian-Packagemanagement verwalten zu können.

[1] http://www.infnet.verein.de/portables_p ... tools.html
[2] http://www.debian.org/doc/maint-guide

[rakim]

hallo garibaldi!!

immer wenn ich ein programm aus den sourcen baue, verwende ich
"checkinstall" zum erstellen meiner .deb pakete. checkinstall
kann rpm,debian und slackware pakete erzeugen.
das hat den vorteil das du mit der klassischen methode arbeiten
kannst, plattform unabhängig bist und hinterher ein paket hast, das
du einfach in/deinstallieren kannst.


mfg rakim

[h-man]

...
Vorweg: Ich bin ein Neuling in Sachen Kompilieren und etwas verwirrt von den verschiedenen Möglichkeiten, ein bestimmtes Programm aus den Quellen zu kompilieren.
...

hy, ergänzend wollte ich noch den begriff "kompilieren" retten.

weder dein a, noch b noch c sind "kompilieren" im eigentlichen sinn. alle deine aufgezählten schritte (a, b, c) beinhalten zwar einen kompiliervorgang, aber es passieren zuvor und danach noch andere dinge, z.b. configurationsdateien erstellen und pakete bauen.

kompilieren ist z.b.:

Code: Alles auswählen

gcc -O2 -o test test.c

denn damit übersetzt du den quelltext in test.c in ein kompilat und verlinkst es mit bibliotheken. vereinfacht gesagt

mehr dazu unter http://de.wikipedia.org/wiki/Kompilieren

[Aresius]

kompilieren ist z.b.:

Code: Alles auswählen

gcc -O2 -o test test.c

denn damit übersetzt du den quelltext in test.c in ein kompilat und verlinkst es mit bibliotheken. vereinfacht gesagt

Naja, ganze genau genommen führt das aber
1. preprocessing
2. compilation
3. assembly
4. linking
aus

NUR compilieren im engsten Sinne (also übersetzen von C in Assembler) würde

Code: Alles auswählen

gcc -S test.i

Aber hast schon recht (war ja vereinfacht gesagt)

PS: Musste die Syntax auch schnell nachschauen

[garibaldi]

@Aresius: Danke für die Erklärungen und links! Wenn ich's recht verstanden habe, sind Methoden b/c zunächst vorzuziehen, da mein Paketmanagement damit zurande kommt. Falls die nicht funktionieren, Methode a nehmen. Bleibt noch die Frage: Wohin mit den selbstgebauten .debs? Ist es besser, diese separat liegen zu haben, oder sollen die dahin, wo auch die anderen sind?

@rakim: Hmm, also noch eine Methode

@h-man + Aresius Ihr solltet euch mal zu 'nem Ehrenhandel treffen

[peschmae]

@Aresius: Danke für die Erklärungen und links! Wenn ich's recht verstanden habe, sind Methoden b/c zunächst vorzuziehen, da mein Paketmanagement damit zurande kommt.

Ja, aber das geht natürlich wenn schon einer ein Debianpaket gebaut hat. Also eigentlich ist das dann nur Sinnvoll für Backports und das Einspielen kleiner Patches. Ansonsten kannst du ja genau so gut das offizielle Paket verwenden.

Bleibt noch die Frage: Wohin mit den selbstgebauten .debs? Ist es besser, diese separat liegen zu haben, oder sollen die dahin, wo auch die anderen sind?

Wo liegen denn die anderen? Auf jeden Fall musst du das installieren - mit dpkg -i $file.deb und dann kannst dus eigentlich wieder löschen.

MfG Peschmä

[Aresius]

peschmea sagt es, wenn schon Binärpakete vorliegen (meistens der Fall wenn es dsc, diff und org in der Kombination gibt), Du dem Paketauthor traust (also nicht den Code nach Malware durchsuchen willst) und keine eigenen Patches integrieren willst, dann ist es einfacher das Binary zu installieren. Generell würde ich das mal zumindest für alle offiziellen Debianpakete voraussetzen. Wenn Du denen nicht traust solltest ne andere Distrib nehmen

Wo die anderen liegen würde mich auch interessieren.

Für gewöhnlich benutzt man unter Debian apt bzw ein frontend davon wie aptitude zum Paketmanagement, weil man sich mit dpkg direkt selbst um das auflösen von Abhängigkeiten kümmern muss. Nähere Infos bei [1].

Ich empfehle für selbst gebaute Pakete immer gleich ein lokales apt-Repository anzulegen und in sources.list einzutragen, auch wenn man natürlich schon etwas lernt wenn man dpkg mal manuell anwendet. Wie man ein lokales Repository anlegt ist bei [2] erklärt.

Garibaldi, Du scheinst einen bestimmten Fall im Hinterkopf zu machen, vielleicht schilderst Du am besten mal, was Du im Moment eigentlich machen willst?

[1] http://wiki.debianforum.de/SoftwareVerwalten
[2] http://arminstraub.de/browse.php?page=l ... repository

[garibaldi]

@peschmae und Aresius: Jepp, wenn binarys schon da sind, nutze ich die auch. Entweder mit aptitude als Kommando, wenn schon genau weiß, welches Paket ich (de-)installieren will, oder als UI, wenn ich mal in Ruhe die Abhängigkeiten oder Paketvorschläge anschauen möchte.

Garibaldi, Du scheinst einen bestimmten Fall im Hinterkopf zu machen, vielleicht schilderst Du am besten mal, was Du im Moment eigentlich machen willst?

Die Nachfrage war eher prinzipieller Natur, denn ich bin immer mal wieder auf Programme/Versionen gestoßen, die für sarge nicht zur Verfügung stehen. Das letzte, was ich kompilierte, war das Paket coreutils, weil ich einen patch zur Forttschrittsanzeige für große Dateien bei cp/mv einspielen wollte. Das hat nach dieser Anleitung auch wunderbar geklappt.

Ein Problem hatte ich zunächst mit dem bauen (okay, nicht kompilieren ) von initng. Da gab's nämlich keine ./configure, sondern im README wurde cmake empfohlen. Das hat wegen Abhängigkeitsproblemen nicht geklappt; aber mit fakeroot konnte ich ein .deb bauen.

Ich empfehle für selbst gebaute Pakete immer gleich ein lokales apt-Repository anzulegen und in sources.list einzutragen...

Guter Tipp, danke! Gebaut habe ich meine .debs auch immer mit # dpkg -i, aber es ist wohl auch praktischer, wenn apt auch die Quellen kennt.

Gruß, garibaldi