Frage Lernen, Dinge aus der Quelle zu kompilieren (unter Unix / Linux / OSX)


Während ich Software aus Paketen (MacPorts / apt-get) wo immer möglich installiere, muss ich oft Pakete aus der Quelle kompilieren. ./configure && make && sudo make install ist normalerweise genug, aber manchmal funktioniert es nicht - und wenn nicht, bleibe ich oft stecken. Dies bezieht sich fast immer auf andere Bibliotheksabhängigkeiten.

Ich möchte Folgendes lernen:

  • Wie finde ich heraus, auf welche Argumente ich eingehen soll? ./configure?
  • Wie funktionieren Shared Libraries unter OS X / Linux - wo leben sie auf dem Dateisystem, wie ./configure && make findet sie, was tatsächlich passiert, wenn sie dagegen gebunden sind
  • Was sind die tatsächlichen Unterschiede zwischen einer gemeinsam genutzten und einer statisch verknüpften Bibliothek? Warum kann ich nicht einfach alles statisch verknüpfen (RAM und Festplattenplatz sind heutzutage billig) und damit seltsame Konflikte bei der Bibliotheksversion vermeiden?
  • Wie kann ich feststellen, welche Bibliotheken ich installiert habe und welche Versionen?
  • Wie kann ich mehr als eine Version einer Bibliothek installieren, ohne mein normales System zu beschädigen?
  • Wenn ich bin das Installieren von Daten aus der Quelle auf einem System, das sonst mit Paketen verwaltet wird, was ist der sauberste Weg?
  • Angenommen, ich schaffe es, etwas findiges aus der Quelle zu kompilieren, wie kann ich das dann verpacken, damit andere Leute nicht durch die gleichen Reifen springen müssen? Besonders auf OS X ....
  • Was sind die Befehlszeilen-Tools, die ich beherrschen muss, um in diesem Zeug gut zu werden? Sachen wie Otool, Pkg-Config usw.

Ich bin bereit, hier ziemlich viel Zeit und Mühe zu investieren - ich möchte nicht unbedingt direkte Antworten auf die oben genannten Fragen, ich würde eher Empfehlungen zu Büchern / Tutorials / FAQs bekommen, die ich lesen kann Wissen muss ich verstehen, was eigentlich vor sich geht und damit Probleme selbst herausfinden.


45
2017-07-27 08:48


Ursprung




Antworten:


Ich entschuldige mich dafür, alles direkt beantwortet zu haben, aber ich kenne keine nützlichen Tutorials, FAQs usw. Im Grunde genommen sind 8 Jahre Desktop-Apps (die ich verteile), Frustration und Googeln:

1. Wie finde ich heraus, welche Argumente an ./configure übergeben werden?

Übe wirklich. Autotools ist einfach genug, da es konsistent ist. Aber es gibt viele Sachen da draußen mit CMake oder benutzerdefinierten Build-Skripten. Generell sollten Sie nichts konfigurieren müssen, es sollte herausfinden, ob Ihr System Foo-Tool oder nicht erstellen kann.

Configure und GNU-Tools suchen in /, / usr und / usr / local nach Abhängigkeiten. Wenn Sie etwas irgendwo anders installieren (was die Verwaltung der Abhängigkeit durch MacPorts oder Fink schmerzhaft macht), müssen Sie ein Flag übergeben, um die Shell-Umgebung zu konfigurieren oder zu ändern, damit GNU-Tools diese Abhängigkeiten finden.

2. Wie funktionieren Shared Libraries unter OS X / Linux - wo sie auf dem Dateisystem leben, wie ./configure && make sie findet, was passiert eigentlich, wenn sie verlinkt werden?

Unter Linux müssen sie in einem Pfad installiert werden, den der Dynamic Linker finden kann, dies ist definiert durch die LD_LIBRARY_PATHUmgebungsvariable und der Inhalt von /etc/ld.conf. Auf Mac ist es für die meisten Open-Source-Software fast immer gleich (außer es ist ein Xcode-Projekt). Außer der env-Variable ist DYLD_LIBRARY_PATH stattdessen.

Es gibt einen Standardpfad, nach dem der Linker nach Bibliotheken sucht. Es ist / lib: / usr / lib: / usr / local / lib

Sie können dies ergänzen, indem Sie die CPATH-Variable oder CFLAGS oder eine beliebige Anzahl anderer Umgebungsvariablen wirklich (bequemerweise kompliziert) verwenden. Ich schlage CFLAGS so vor:

export CFLAGS = "$ CFLAGS -L / neu / Pfad"

Der Parameter -L fügt dem Verbindungspfad hinzu.

Modernes Zeug verwendet das pkg-config-Tool. Bei der Installation von modernem Zeug wird auch eine .pc-Datei installiert, die die Bibliothek beschreibt und beschreibt, wo sie sich befindet und wie sie verlinkt wird. Dies kann das Leben erleichtern. Aber es kommt nicht mit OS X 10.5, also müssen Sie das auch installieren. Auch viele grundlegende Deps unterstützen es nicht.

Der Vorgang der Verknüpfung ist nur "diese Funktion zur Laufzeit auflösen", wirklich ist es eine große String-Tabelle.

3. Was sind die tatsächlichen Unterschiede zwischen einer gemeinsam genutzten und einer statisch verknüpften Bibliothek? Warum kann ich nicht einfach alles statisch verknüpfen (RAM und Festplattenplatz sind heutzutage billig) und damit seltsame Konflikte bei der Bibliotheksversion vermeiden?

Wenn Sie eine Verknüpfung zu einer statischen Bibliotheksdatei herstellen, wird der Code Teil Ihrer Anwendung. Es wäre, als gäbe es eine riesige .c-Datei für diese Bibliothek, und Sie haben sie in Ihre Anwendung kompiliert.

Dynamische Bibliotheken haben den gleichen Code, aber wenn die App ausgeführt wird, wird der Code zur Laufzeit in die App geladen (vereinfachte Erklärung).

Sie können statisch auf alles verlinken, leider machen das kaum Build-Systeme. Sie müssten Build-Systemdateien manuell bearbeiten (zB Makefile.am oder CMakeLists.txt). Dies ist jedoch wahrscheinlich lohnenswert, wenn Sie regelmäßig Dinge installieren, für die unterschiedliche Versionen von Bibliotheken erforderlich sind, und das gleichzeitige Installieren von Abhängigkeiten schwierig ist.

Der Trick besteht darin, die Verbindungslinie von -lfoo zu -l / path / zu / static / foo.a zu ändern

Sie können wahrscheinlich finden und ersetzen. Überprüfen Sie anschließend, ob das Tool nicht mit .so oder dylib über ldd foo oder otool -L foo verbunden ist

Ein anderes Problem sind nicht alle Bibliotheken, die zu statischen Bibliotheken kompiliert werden. Viele tun es. Aber dann haben MacPorts oder Debian entschieden, es nicht zu versenden.

4. Wie kann ich feststellen, welche Bibliotheken ich installiert habe und welche Versionen?

Wenn Sie pkg-config-Dateien für diese Bibliotheken haben, ist es einfach:

pkg-config --list-all

Sonst kann man oft nicht so leicht. Die Dylib kann einen Soname haben (zB. Foo.0.1.dylib, der Soname ist 0.1), der der Version der Library entspricht. Dies ist jedoch nicht erforderlich. Das Soname ist eine binäre Berechenbarkeitsfunktion, Sie müssen den Hauptteil des Sonames stoßen, wenn Sie das Format der Funktionen in der Bibliothek ändern. So kannst du zB bekommen. Version 14.0.5 soname für eine 2.0 Bibliothek. Obwohl das nicht üblich ist.

Ich war frustriert über diese Art von Dingen und habe eine Lösung dafür auf Mac entwickelt, und ich spreche als nächstes darüber.

5. Wie kann ich mehr als eine Version einer Bibliothek installieren, ohne mein normales System zu beschädigen?

Meine Lösung dazu ist hier: http://github.com/mxcl/homebrew/

Ich mag es, von der Quelle zu installieren, und wollte ein Tool, das es leicht gemacht hat, aber mit etwas Paketverwaltung. Also mit Homebrew bau ich zB. wget mich aus der Quelle, aber stellen Sie sicher, dass Sie auf ein spezielles Präfix installieren:

/usr/local/Cellar/wget/1.1.4

Ich benutze dann das homebrew Werkzeug, um das alles in / usr / local zu verlinken, also habe ich noch / usr / local / bin / wget und /usr/local/lib/libwget.dylib

Später, wenn ich eine andere Version von wget brauche, kann ich es parallel installieren und nur die Version ändern, die in die / usr / local-Struktur eingebunden ist.

6. Wenn ich Sachen von der Quelle auf einem System installiere, das sonst mit Paketen verwaltet wird, was ist der sauberste Weg?

Ich glaube, der Homebrew-Weg ist am saubersten, also benutze ihn oder mache das Äquivalent. Installieren Sie die Datei unter / usr / local / pkgs / name / version und verknüpfen Sie den Rest mit SymLink oder Hard Link.

Verwenden Sie / usr / local. Jedes Build-Tool, das existiert, sucht dort nach Abhängigkeiten und Headern. Dein Leben wird sein viel einfacher.

7. Wenn ich es schaffe, etwas aus der Quelle zu kompilieren, wie kann ich das dann verpacken, damit andere Leute nicht durch die gleichen Reifen springen müssen? Besonders auf OS X ....

Wenn es keine Abhängigkeiten gibt, können Sie das Build-Verzeichnis tarieren und es an jemand anderen weitergeben, der dann "make install" ausführen kann. Allerdings kann man das nur für genau die gleichen Versionen von OS X zuverlässig tun. Unter Linux wird es wahrscheinlich für ähnliche Linux (zB Ubuntu) mit der gleichen Kernel-Version und libc-Nebenversion funktionieren.

Der Grund, warum es nicht einfach ist, Binärdateien unter Unix zu verteilen, ist die Binärkompatibilität. Die GNU-Leute und alle anderen ändern oft ihre binären Schnittstellen.

Verteilen Sie im Grunde keine Binärdateien. Die Dinge werden wahrscheinlich auf sehr seltsame Weise brechen.

Am Mac ist es am besten, ein Macports-Paket zu erstellen. Jeder benutzt Macports. Unter Linux gibt es so viele verschiedene Build-Systeme und -Kombinationen. Ich glaube nicht, dass es einen besseren Rat gibt, als einen Blog-Eintrag darüber zu schreiben, wie Sie in einer seltsamen Konfiguration das x-Tool erfolgreich erstellt haben.

Wenn Sie eine Paketbeschreibung (für Macports oder Homebrew) machen, kann jeder dieses Paket installieren, und es löst auch die Abhängigkeitsprobleme. Dies ist jedoch oft nicht einfach, und es ist auch nicht einfach, Ihr Macportrezept in den Macports-Hauptbaum aufzunehmen. Macports unterstützt auch keine exotischen Installationstypen, sie bieten eine Auswahl für alle Pakete.

Eines meiner zukünftigen Ziele bei Homebrew ist es, einen Link auf einer Website anzuklicken (zB homebrew: // blah und es wird das Ruby-Skript herunterladen, die Deps für dieses Paket installieren und dann die App erstellen. Aber ja, noch nicht fertig, aber nicht zu kompliziert, wenn man bedenkt, welches Design ich gewählt habe.

8. Was sind die Befehlszeilen-Tools, die ich beherrschen muss, um in diesem Zeug gut zu werden? Sachen wie Otool, Pkg-Config usw.

Otool ist wirklich nur danach nützlich. Es sagt Ihnen, worauf die gebaute Binärdatei verweist. Wenn Sie die Abhängigkeiten eines Werkzeugs herausfinden, das Sie erstellen müssen, ist es nutzlos. Dasselbe gilt für pkg-config, da Sie die Abhängigkeit bereits installiert haben, bevor Sie sie verwenden können.

Meine Werkzeugkette ist, lesen Sie die README und INSTALL-Dateien, und führen Sie eine Konfiguration --help. Beobachten Sie die Build-Ausgabe, um zu überprüfen, ob sie fehlerfrei ist. Analysiere alle Buildfehler. Vielleicht in Zukunft fragen Sie auf Serverfault :)


38
2017-07-27 13:08



Interessanterweise scheint Homebrew Portage sehr ähnlich zu sein (der Paketmanager von Gentoo Linux). Klingt nach einem schönen Stück Arbeit. - David Z


Dies ist ein riesiges Thema, also beginnen wir mit gemeinsamen Bibliotheken unter Linux (ELF unter Linux und Mach-O unter OS X), Ulrich Drepper hat eine gute Einführung in das Schreiben von DSOs (Dynamic Shared Objects), die eine Geschichte von Shared Libraries auf Linux abdeckt, die hier verfügbar ist, einschließlich warum sie wichtig sind

Ulrich beschreibt auch warum Statische Verknüpfungen gelten als schädlich Einer der wichtigsten Punkte sind Sicherheitsupdates. Pufferüberläufe in einer gemeinsamen Bibliothek (zB zlib), die ausgiebig statisch verknüpft ist, können einen enormen Overhead für Distributionen verursachen - dies geschah mit zlib 1.1.3 (Red Hat-Hinweis)

ELF

Die Linker ld.so manuelle Seite

man ld.so 

erklärt die grundlegenden Pfade und Dateien, die beim dynamischen Verknüpfen der Laufzeit beteiligt sind. Auf modernen Linux-Systemen sehen Sie zusätzliche Pfade, die über /etc/ld.so.conf.d/ hinzugefügt werden und normalerweise über einen Glob-Include in /etc/ld.so.conf hinzugefügt werden.

Wenn Sie sehen möchten, was dynamisch über Ihre ld.so-Konfiguration verfügbar ist, können Sie es ausführen

ldconfig -v -N -X

Wenn Sie das DSO-Howto lesen, sollten Sie ein gutes Grundwissen erlangen, um dann zu verstehen, wie diese Prinzipien für Mach-O unter OS X gelten.

Macho

Unter OS X ist das Binärformat Mach-O. Lokale Systemdokumentation für den Linker ist

man dyld

Das Mach-Format-Dokumentation ist von Apple erhältlich

UNIX-Erstellungstools

Das Gemeinsame configure, make, make install Prozess wird in der Regel von GNU Autotools zur Verfügung gestellt, die eine Online-Buch Das deckt einen Teil der Geschichte des configure / build-Splits und der GNU-Toolchain ab. Autokonf verwendet Tests, um die Verfügbarkeit von Features auf dem von ihm verwendeten Zielerstellungssystem zu ermitteln M4 Makrosprache um das zu fahren. Automake ist im Grunde eine Template-Methode für Makefiles, wobei das Template im Allgemeinen Makefile.am genannt wird und Makefile.in ausgibt, das die Ausgabe von autoconf (das configure-Skript) in ein Makefile konvertiert.

Das GNU Hallo Programm ist ein gutes Beispiel für das Verständnis der GNU-Toolchain - und das Handbuch enthält Autotools-Dokumentation.


11
2017-07-27 09:18





Simon! Ich weiß wie du dich fühlst; Ich hatte auch mit diesem Teil des Linux-Lernens zu kämpfen. Basierend auf meinen eigenen Erfahrungen, habe ich ein Tutorial über einige der Artikel geschrieben, die Sie ansprechen (meistens als Referenz für mich selbst!): http://easyaspy.blogspot.com/2008/12/buildinginstalling-application-from.html. Ich denke, dass Sie meine Notiz darüber schätzen werden, wie einfach Python-Anwendungen zum Erstellen / Installieren sind. :)

Hoffe, dass dies hilft! Und glücklich zusammenstellen.

Tim Jones


Erstellen / Installieren einer Anwendung von der Quelle in Ubuntu Linux

Während die Ubuntu-Repositories voll mit großartigen Anwendungen sind, stößt man irgendwann einmal auf das "Must-Have" -Tool, das nicht in den Repositories ist (oder kein Debian-Paket hat) oder man braucht ein neuere Version als in den Repositories. Wie geht's? Nun, Sie müssen die Anwendung von der Quelle erstellen! Mach dir keine Sorgen, es ist wirklich nicht so kompliziert wie es klingt. Hier sind ein paar Tipps, die auf meinen Erfahrungen basieren, dass ich vom Rang-Amateur bin! (Während ich Ubuntu für dieses Beispiel verwende, sollten die allgemeinen Konzepte für die meisten Unix / Linux-Distributionen wie Fedora und sogar die Cygwin-Plattform unter Windows gelten.)

Der grundlegende Prozess der Erstellung (Kompilierung) der meisten Anwendungen aus der Quelle folgt dieser Sequenz: configure -> compile -> install. Die typischen Unix / Linux-Befehle, um diese Dinge zu tun sind: config -> make -> make install. In einigen Fällen werden Sie sogar Webseiten finden, die zeigen, dass all diese zu einem einzigen Befehl zusammengefasst werden können:

$ config && make && make install

Natürlich geht dieser Befehl davon aus, dass in diesen Schritten keine Probleme auftreten. Hier kommt der Spaß ins Spiel!

Fertig machen

Wenn Sie noch nie eine Anwendung von der Quelle auf Ihrem System kompiliert haben, müssen Sie diese wahrscheinlich mit einigen allgemeinen Entwicklungswerkzeugen, wie z gcc Compiler-Suite, einige allgemeine Header-Dateien (denken Sie daran als Code, der bereits von jemand anderem geschrieben wurde, der von dem Programm verwendet wird, das Sie installieren) und das make-Tool. Glücklicherweise gibt es in Ubuntu ein Metapaket namens build-essential das wird davon installieren. Um es zu installieren (oder einfach sicherzustellen, dass Sie es bereits haben!), Führen Sie diesen Befehl im Terminal aus:

$ sudo apt-get install build-essential

Laden Sie nun die Anwendungsquelldateien herunter und speichern Sie sie in einem Verzeichnis, für das Sie über Lese- / Schreibberechtigungen verfügen, z. B. Ihr "Home" -Verzeichnis. In der Regel befinden sich diese in einer Archivdatei mit der Dateierweiterung von beiden .tar.gz oder .tar.bz2. Das .tar bedeutet einfach, dass es sich um ein "Tape-Archiv" handelt, bei dem es sich um eine Gruppierung von Dateien handelt, die ihre relative Verzeichnisstruktur bewahrt. Das .gz steht für gzip (GNU zip), ein beliebtes Unix / Linux-Komprimierungsformat. Ähnlich, die .bz2 steht für bzip2, ein neueres Komprimierungsformat, das eine höhere Komprimierung (kleinere komprimierte Dateigröße) als gzip bietet.

Nachdem Sie die Quelldatei heruntergeladen haben, öffnen Sie ein Terminalfenster (System-Terminal aus dem Ubuntu-Menü) und wechseln Sie in das Verzeichnis, in dem Sie Ihre Datei gespeichert haben. (Ich werde verwenden ~/download in diesem Beispiel. Hier ist '~' eine Verknüpfung zu Ihrem "Home" -Verzeichnis.) Verwenden Sie den Befehl tar, um die Dateien aus der heruntergeladenen Archivdatei zu extrahieren:

Wenn Ihre Datei ein gzip-Archiv ist (z. B. mit .tar.gz), benutze den Befehl:

            $ tar -zxvf filename.tar.gz

Wenn Ihre Datei ein bzip2-Archiv ist (z. B. endet mit .tar.bz2), benutze den Befehl:

            $ tar -jxvf filename.tar.gz

Tipp: Wenn Sie nicht möchten   erinnere dich an die gesamte Befehlszeile   Schalter zum Extrahieren von Archiven, I   empfehlen, eines (oder beide) von   diese Dienstprogramme: dtrx (mein Favorit!)   oder Deko (beliebter). Mit beiden   diese Dienstprogramme, geben Sie einfach die   Name des Dienstprogramms (dtrx oder deco) und   der Dateiname, es tut alles   sich ausruhen. Beide "wissen", wie   handhaben fast jedes Archivformat, das   Sie werden wahrscheinlich rüberrennen und sie   habe eine große Fehlerbehandlung.

Wenn Sie aus der Quelle erstellen, gibt es zwei häufige Arten von Fehlern, denen Sie wahrscheinlich begegnen:

  1. Konfigurationsfehler treten auf, wenn Sie das Konfigurationsskript (normalerweise mit dem Namen config oder configure) ausführen, um ein Makefile zu erstellen, das für Ihre Einrichtung spezifisch ist.
  2. Compiler-Fehler treten auf, wenn Sie den make-Befehl ausführen (nachdem das Makefile generiert wurde) und der Compiler den benötigten Code nicht finden kann.

Wir werden uns jeden einzelnen anschauen und besprechen, wie wir sie lösen können.

Konfigurations- und Konfigurationsfehler

Nachdem Sie die Quellcodearchivdatei im Terminal extrahiert haben, sollten Sie in das Verzeichnis wechseln, das die extrahierten Dateien enthält. Normalerweise entspricht dieser Verzeichnisname dem Namen der Datei (ohne die .tar.gz oder .tar.bz2 Erweiterung). Manchmal ist der Verzeichnisname jedoch nur der Name der Anwendung ohne Versionsinformationen.

Suchen Sie im Quellverzeichnis nach a README Datei und / oder ein INSTALL Datei (oder etwas mit ähnlichen Namen). Diese Dateien enthalten in der Regel nützliche Informationen zum Erstellen / Kompilieren der Anwendung und zum Installieren dieser Anwendung, einschließlich Informationen zu Abhängigkeiten. "Abhängigkeiten" sind nur ein fantastischer Name für andere Komponenten oder Bibliotheken, die für eine erfolgreiche Kompilierung benötigt werden.

Nachdem du das gelesen hast README und / oder INSTALL Datei (und hoffentlich sah alle relevanten Online-Dokumentation für die Anwendung), suchen Sie nach einer ausführbaren Datei (hat die "x" Berechtigung für die Datei festgelegt) namens config oder configure. Manchmal hat die Datei möglicherweise eine Erweiterung, z .sh (z.B., config.sh). Dies ist normalerweise ein Shell-Skript, das einige andere Dienstprogramme ausführt, um zu bestätigen, dass Sie eine "vernünftige" Umgebung zum Kompilieren haben. Mit anderen Worten, es wird überprüft, ob Sie alles installiert haben, was Sie benötigen.

Tipp: Wenn dies auf Python basiert   Anwendung, anstelle einer Konfigurationsdatei,   Sie sollten eine Datei namens finden setup.py.   Python-Anwendungen sind in der Regel sehr   einfach zu installieren. Um das zu installieren   Anwendung als root (z. B. Sudo   vor dem folgenden Befehl   unter Ubuntu), führe diesen Befehl aus:

    $ python setup.py install

Das sollte alles sein, was Sie brauchen   tun. Sie können den Rest davon überspringen   Tutorial und direkt zur Verwendung   und genieße deine Bewerbung.

Führen Sie das Konfigurationsskript im Terminal aus. Normalerweise können (und sollten!) Sie Ihr Konfigurationsskript mit Ihrem normalen Benutzerkonto ausführen.

$ ./config

Das Skript zeigt einige Nachrichten an, um Ihnen eine Vorstellung davon zu geben, was es macht. Häufig gibt das Skript einen Hinweis darauf, ob es erfolgreich war oder fehlgeschlagen ist, und, falls es fehlgeschlagen ist, einige Informationen über die Ursache des Fehlers. Wenn Sie keine Fehlermeldungen erhalten, können Sie normalerweise davon ausgehen, dass alles in Ordnung war.

Wenn Sie kein Skript finden, das wie ein Konfigurationsskript aussieht, bedeutet dies normalerweise, dass die Anwendung sehr einfach ist und plattformunabhängig ist. Dies bedeutet, dass Sie einfach zum unten stehenden Build / Compile-Schritt springen können, da das bereitgestellt wird Makefilesollte auf jedem System funktionieren.

Ein Beispiel

In diesem Tutorial werde ich den textbasierten RSS-Reader namens Newsbeuter als Beispiel für die Arten von Fehlern verwenden, die beim Erstellen Ihrer Anwendung auftreten können. Für Newsbeuter lautet der Name des Konfigurationsskriptes config.sh. Auf meinem System, wenn ich renne config.sh, treten die folgenden Fehler auf:

tester@sitlabcpu22:~/download/newsbeuter-1.3$ ./config.sh
Checking for package sqlite3... not found

You need package sqlite3 in order to compile this program.
Please make sure it is installed.

Nachdem ich einige Nachforschungen angestellt hatte, fand ich, dass die sqlite3 Anwendung wurde installiert. Aber da ich versuche, aus der Quelle zu bauen, ist dies ein Tipp, was config.sh sucht eigentlich nach den Entwicklungsbibliotheken (Headers) für sqlite3. In Ubuntu haben die meisten Pakete ein zugeordnetes Entwicklungs-Gegenstück-Paket, das endet -dev. (Andere Plattformen wie Fedora verwenden oft ein Paketsuffix von -devel für die Entwicklungspakete.)

Um das passende Paket für die sqlite3 Entwicklungspaket, können wir das verwenden apt-cache Dienstprogramm in Ubuntu (und in ähnlicher Weise die yum Dienstprogramm in Fedora):

tester@sitlabcpu22:~/download/newsbeuter-1.3$ sudo apt-cache search sqlite

Dieser Befehl gibt eine ziemlich große Liste von Ergebnissen zurück, also müssen wir ein wenig detektivische Arbeit machen, um festzustellen, welches das richtige Paket ist. In diesem Fall stellt sich das entsprechende Paket heraus libsqlite3-dev. Beachten Sie, dass manchmal das Paket, nach dem wir suchen, das lib Präfix, anstatt nur den gleichen Paketnamen plus -dev. Dies liegt daran, dass wir manchmal nur nach einer gemeinsam genutzten Bibliothek suchen, die von vielen verschiedenen Anwendungen verwendet werden kann. Installieren libsqlite3-devFühren Sie den typischen Befehl apt-get install im Terminal aus:

tester@sitlabcpu22:~/download/newsbeuter-1.3$ sudo apt-get install libsqlite3-dev

Jetzt müssen wir rennen config.sh um sicherzustellen, dass wir dieses Abhängigkeitsproblem gelöst haben und keine Abhängigkeitsprobleme mehr haben. (Ich werde es hier nicht zeigen, im Fall von Newsbeuter musste ich aber auch den libcurl4-openssl-dev Paket. Außerdem, wenn Sie ein Entwicklungspaket installieren (wie libsqlite3-dev) und das zugehörige Anwendungspaket (z. B. sqlite3) ist noch nicht installiert, die meisten Systeme installieren automatisch das zugehörige Anwendungspaket zur gleichen Zeit.

Wenn die Konfiguration erfolgreich ausgeführt wird, werden als Ergebnis eine oder mehrere make-Dateien erstellt. Diese Dateien werden normalerweise benannt Makefile (Denken Sie daran, dass der Dateiname unter Unix / Linux von Bedeutung ist!). Wenn das Build-Paket Unterverzeichnisse enthält, z srcusw., jedes dieser Unterverzeichnisse enthält a Makefile, auch.

Fehler beim Erstellen und Kompilieren

Jetzt sind wir bereit, die Anwendung tatsächlich zu kompilieren. Dies wird oft als Bauen bezeichnet und der Name ist dem realen Prozess des Konstruierens von etwas entlehnt. Die verschiedenen "Teile" der Anwendung, bei denen es sich typischerweise um mehrere Quellcodedateien handelt, werden miteinander kombiniert, um die Gesamtanwendung zu bilden. Das make-Dienstprogramm verwaltet den Build-Prozess und ruft andere Anwendungen wie Compiler und Linker auf, um die Arbeit tatsächlich auszuführen. In den meisten Fällen führen Sie einfach make (mit Ihrem regulären Benutzerkonto) aus dem Verzeichnis aus, in dem Sie die Konfiguration ausgeführt haben. (In einigen Fällen, wie das Kompilieren von Anwendungen, die mit der Qt-Bibliothek geschrieben wurden, müssen Sie stattdessen eine andere "Wrapper" -Anwendung wie qmake ausführen README und / oder INSTALLDokumente für Details.)

Wie beim obigen Konfigurationsskript werden beim Ausführen von make (oder dem ähnlichen Dienstprogramm) im Terminal einige Meldungen über die Ausführung und Warnungen und Fehler angezeigt. Sie können Warnungen normalerweise ignorieren, da sie hauptsächlich für die Entwickler der Anwendung gedacht sind und ihnen sagen, dass einige Standardmethoden verletzt werden. Normalerweise haben diese Warnungen keinen Einfluss auf die Anwendungsfunktion. Auf der anderen Seite müssen Compiler-Fehler behandelt werden. Mit Newsbeuter, als ich ran ging, ging es für eine Weile gut, aber dann bekam ich einen Fehler:

tester@sitlabcpu22:~/download/newsbeuter-1.3$ make
...
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/configparser.o -c src/configparser.cpp
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/colormanager.o -c src/colormanager.cpp
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:5:18: error: stfl.h: No such file or directory
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:33: error: ISO C++ forbids declaration of \u2018stfl_form\u2019 with no type
./include/stflpp.h:33: error: expected \u2018;\u2019 before \u2018*\u2019 token
./include/stflpp.h:34: error: ISO C++ forbids declaration of \u2018stfl_ipool\u2019 with no type
./include/stflpp.h:34: error: expected \u2018;\u2019 before \u2018*\u2019 token
make: *** [src/colormanager.o] Error 1

Der Erstellungsprozess wird beendet, sobald der erste Fehler auftritt. Compiler-Fehler behandeln kann manchmal schwierig sein. Sie müssen die Fehler für einige Hinweise auf das Problem betrachten. In der Regel ist das Problem, dass einige Header-Dateien, die normalerweise eine Erweiterung von haben .h oder .hpp, fehlen. Im Falle des obigen Fehlers ist (oder sollte!) Klar, dass das Problem darin besteht stfl.h Header-Datei kann nicht gefunden werden. Wie in diesem Beispiel gezeigt, möchten Sie die ersten Zeilen der Fehlernachricht anzeigen und nach unten suchen, um die zugrunde liegende Ursache des Problems zu finden.

Nachdem ich die Dokumentation von Newsbeuter gesehen habe (was ich hätte tun sollen, bevor ich anfing, aber dann wäre dieser Teil des Tutorials nicht sehr sinnvoll!), Fand ich, dass es eine 3rd-Party-Bibliothek namens STFL benötigt. Was machen wir in diesem Fall? Nun, im Wesentlichen wiederholen wir genau diesen Prozess für die erforderliche Bibliothek: Beschaffen Sie die Bibliothek und führen Sie den configure-build-install-Prozess dafür aus und nehmen Sie dann die Erstellung der gewünschten Anwendung wieder auf. Zum Beispiel musste ich im Fall von STFL die libncursesw5-dev Paket für es richtig zu bauen. (In der Regel ist es nicht notwendig, den Konfigurationsschritt in unserer ursprünglichen Anwendung nach der Installation einer anderen erforderlichen Anwendung zu wiederholen, aber es tut auch nichts weh.)

Nach erfolgreicher Installation des STFL-Toolkits lief der make-Prozess für Newsbeuter erfolgreich. Der Erstellungsprozess nimmt normalerweise dort auf, wo er aufhört (an der Stelle des Fehlers). Daher werden alle Dateien, die bereits erfolgreich kompiliert wurden, nicht neu kompiliert. Wenn Sie alles neu kompilieren möchten, können Sie make clean ausführen, um alle kompilierten Objekte zu entfernen, und make erneut ausführen.

Installieren

Nachdem der Buildprozess erfolgreich abgeschlossen wurde, können Sie die Anwendung installieren. In den meisten Fällen, um die Anwendung in den allgemeinen Bereichen des Dateisystems zu installieren (z.B. /usr/bin oder /usr/share/binusw.), müssen Sie die Installation als root ausführen. Die Installation ist wirklich der einfachste Schritt im gesamten Prozess. So installieren Sie im Terminallauf:

$ make install

Überprüfen Sie die Ausgabe dieses Prozesses auf Fehler. Wenn alles erfolgreich war, sollten Sie in der Lage sein, den Befehlsnamen im Terminal auszuführen, und er wird gestartet. (Hängen Sie an das Ende der Befehlszeile an, wenn es sich um eine GUI-Anwendung handelt, oder Sie können die Terminalsitzung erst verwenden, wenn die Anwendung beendet ist.)

Wenn Sie eine Anwendung aus der Quelle erstellen, wird normalerweise kein Symbol oder keine Verknüpfung zu den GUI-Menüs in Ubuntu hinzugefügt. Sie müssen dies manuell hinzufügen.

Und das ist im Grunde der Prozess, wenn auch potenziell iterativ, um eine Anwendung von der Quelle in Ubuntu zu erstellen und zu installieren. Nachdem Sie dies nur ein paar Mal getan haben, wird es für Sie zur Selbstverständlichkeit!


9
2017-07-31 14:09



Tim, ich hätte dein Tutorial gerne gelesen, aber der Link, den du gepostet hast, funktioniert nicht. - gareth_bowles


Nun, ./configure --help gibt Ihnen eine Menge Informationen, die von GNU autotools generierte Konfigurationsdateien sind. Das meiste davon kommt auf --with / -, ohne Features zu aktivieren (diese können einen zusätzlichen Parameter benötigen, wie "shared", um zu sagen, wo die Bibliothek zu finden ist).

Andere wichtige sind --prefix (standardmäßig / usr / local / die meiste Zeit), um zu sagen, wo zu installieren ist (wenn Sie Pakete erstellen, möchten Sie dies normalerweise als --prefix = / usr oder vielleicht --prefix = / opt / YourPackage).

Unter Linux werden / lib, / usr / lib und / usr / local / lib in der Regel nach meinem gcc durchsucht und in die Standardkonfiguration von ldconfig aufgenommen. Wenn Sie keinen guten Grund haben, möchten Sie hier Ihre Bibliotheken haben. /etc/ld.so.conf kann jedoch zusätzliche Einträge auflisten.

konfigurieren Sie und machen Sie sie, indem Sie einfach versuchen, "gcc -l" auszuführen und zu sehen, ob es Fehler gibt. Sie können Ihrem CFLAGS-Parameter "-L" hinzufügen, um zusätzliche Suchpfade hinzuzufügen.

Sie können mehrere Versionen installiert haben, und Software, die mit einer älteren Version verknüpft ist, bleibt dagegen verlinkt (run ldd, um die Bindung unter Linux herauszufinden), aber neue Kompilierungen richten sich im Allgemeinen auf die neueste Version einer dynamischen Bibliothek auf Ihrem System.

Die meisten Programme gehen von dynamischen Bibliotheken aus, besonders wenn sie libtool verwenden. Daher können nicht-triviale Anwendungen nicht korrekt statisch erstellt werden.

ls -l ist die beste Wahl, um installierte Bibliotheken zu finden.

Und da habe ich keine Informationen mehr; Wie man gut mit Paketen spielt: weiß nicht. Wenn möglich, versuche ich, Dinge in ein Paket zu verpacken, um das Problem zu vermeiden.


5
2017-07-27 09:11





"Wie finde ich heraus, welche Argumente an ./configure übergeben werden?"

normalerweise: ./configure --help sagt dir was du willst.

"Wie kann ich feststellen, welche Bibliotheken ich installiert habe und welche Versionen?"

Das hängt vom System ab. Ein Weg ist, einfach ein zu tun find /|grep libname|less wie in der Regel Bibliotheksdateien haben die Version im Dateinamen.

"Wie kann ich mehr als eine Version einer Bibliothek installieren, ohne mein normales System zu beschädigen?"

Auch hier kommt es auf das System und die Bibliothek an. sudo make altinstall erstellt einen versionierten Namen für Sie. Bibliotheksdateien werden normalerweise selbst versioniert. Beachten Sie jedoch; Da die Versionen oft Symlinks zu einem "normalisierten" Namen erzeugen, kann dies die Dinge zerstören.

"Wenn ich Sachen von der Quelle auf einem System installiere, das sonst mit Paketen verwaltet wird, was ist der sauberste Weg?"

Verwenden Sie die Parameter --prefix in ./configure und setzen Sie sie irgendwo in /opt ist eine gute Übung zu folgen.

Haftungsausschluss: Ich bin kein Experte, aber ich benutze Linux seit über 5 Jahren von der cmd-Linie (Slackware, CentOS, Redhat, Ubuntu, verschiedene andere und OS X).


3
2017-07-27 09:13





Um ein wenig von Ihrer Frage zu beantworten, habe ich kürzlich einen guten Weg gefunden, um zu sehen, welche Bibliotheken Sie installiert haben und die Versionen (Dies ist unter Linux Debian, also sollte es auch mit anderen Versionen funktionieren).

dpkg --list

Sie sollten eine wirklich lange Liste mit einer solchen Ausgabe erhalten

ii  libssl0.9.8    0.9.8c-4etch5  SSL shared libraries
ii  libssp0        4.1.1-21       GCC stack smashing protection library
ii  libstdc++5     3.3.6-15       The GNU Standard C++ Library v3
ii  libstdc++5-3.3 3.3.6-15       The GNU Standard C++ Library v3 (development
ii  libstdc++6     4.1.1-21       The GNU Standard C++ Library v3

3
2017-07-27 09:12





Simon,

1.) ./configure --help bietet eine gute Menge an Informationen. Ich schlage vor, es zu überprüfen. Im Allgemeinen gibt es Optionen zum Kompilieren von statisch / dynamisch verknüpften Bibliotheken, wenn dies angemessen ist.

2.) Bibliotheken leben im dynamischen Linkerpfad. Dies wird normalerweise in /etc/ld.so.conf festgelegt. Der Linker sucht nach den entsprechenden Bibliotheken, ähnlich wie die PATH-Umgebungsvariable, die mit der zuerst gefundenen übereinstimmt.

3.) Dies führt in der Regel zu Problemen, da Sie alles neu kompilieren müssen, wenn sich eine Bibliotheksversion ändert. Wenn Sie etwas suchen, werden Sie wahrscheinlich eine Menge Gründe finden, warum statisches Linken eine schlechte Idee ist. Ich habe es nicht so lange getan, ich kann es hier nicht wirklich ausführen.

4.) Das ist ein bisschen schwierig. Sie müssen Ihren Bibliothekspfad überprüfen, um absolut sicher zu gehen. Bibliotheken haben in der Regel einen symbolischen Link zu der installierten Version.

z.B. libssh2.so.1 -> libssh2.so.1.0.0

Im Allgemeinen verwalten Benutzer die Bibliotheken und Programme, die sie installieren, indem sie entweder ihre eigenen Debian-Pakete rollen oder eine andere Technik verwenden. Ich verwalte die installierte Software mit Stow (http://www.gnu.org/software/stow/) das ist sehr einfach und installiert die Bibliothek über symbolische Links. Ich finde es einfacher, da ich ein deb / rpm-Paket nicht bauen / installieren / testen muss.

5.) Mehrere Versionen von Bibliotheken können normal in Bibliotheksverzeichnissen installiert werden. Bibliotheken, die mit ausführbaren Dateien verknüpft sind, bleiben mit den Versionen verknüpft, mit denen sie verknüpft waren. Wenn Sie ldd auf einer ausführbaren Datei ausführen, erfahren Sie, mit welchen Bibliotheken die ausführbare Datei verknüpft ist.

6.) Wie ich bereits erwähnt habe, ist es wahrscheinlich die sauberste Lösung, eigene Debian-Pakete zu rollen oder zu verstauen.

7.) Ich kann nicht wirklich für Mac OSX sprechen, aber für Linux ist das Verpackungssystem der Distribution der beste Weg.

8.) Wahrscheinlich wird viel Frustration durch die Verwendung von ldd gelöst werden und herausfinden, welche Version etwas gegen verlinkt ist oder welche Bibliothek, die mit einer ausführbaren Datei verknüpft ist, nicht gefunden werden kann. pkg-config wird Ihnen viel helfen, aber nur für Software, die es benutzt. Es ist nicht Teil des Standard-Autotools-Build-Systems, obwohl es in diesen Tagen beliebt ist.


3
2017-07-27 09:22