Login
Login-Name Passwort


 
Newsletter

Thema: Wann haben Sie zum letzten Mal eine Fremdanwendung kompiliert?

43 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von autarch am Fr, 29. September 2017 um 14:12 #

Gelten bei Arch AUR packages, die unter Umständen durchaus Sourcedateien kompilieren, aber bei denen ich eigentlich nicht eingreifen muss und das ganze wie ein normales Paket installiere?

0
Von needle am Fr, 29. September 2017 um 14:12 #

Warum man kompiliert? Weil man die aktuellsten Patches testen möchte, den letzten Bugfix der gerade eben reingekommen ist auch mitverwenden möchte. Die aktuellste Version des Spiels anspielen will.

Die Desktoprechner heutzutage sind so schnell, dass es mitlerweile keinen Unterschied macht ob man ein Paket aus den quellen baut, oder ein binary installiert. Es sei den es is Firefox oder Libreoffice etc...

In dem Sinne ein schönes Wochenende
the_needle

Dieser Beitrag wurde 1 mal editiert. Zuletzt am 29. Sep 2017 um 14:15.
  • 0
    Von Tuxentier2011 am Sa, 30. September 2017 um 16:46 #

    Als Gentoo-User möchte ich da aber etwas gegenhalten. Ja, kleine Kommandozeilenprogrammchen gehen auf einem dickeren Desktoprechner fix. Aber einen Unterschied macht bei allen anderen dennoch. Vor allem, wenn bei irgendwelchen libs sich so viel geändert hat, daß man hinterher die darauf aufbauenden Programme nochmal rekompilieren muß. Und das erwähnte LibO braucht auf meinem schnellsten Rechner je nach Konfiguration ca. >=1,5 h auf meinem zweitschnellsten Gerät schon um die 5 h. Bei den anderen nehme ich dann doch das binary oder löse es über chroot, falls machbar.

    • 0
      Von needle am So, 1. Oktober 2017 um 17:43 #

      Als Gentoo-User möchte ich da aber etwas gegenahlten. Ja, große Programme wie das erwähnte Libreoffice brauchen bei einem Rechner je nach Konfiguration ca >= 1,5 h. Man kann aber auch distcc benutzen.

      • 1
        Von openWeb am Mo, 2. Oktober 2017 um 00:07 #

        Als Gentoo-User: LibO brauche ich regelmäßig... Mein Rechner läuft 24/7... Warum also sollte mich ein Update von 1,5h stören? Dank 32GB Ram (war billig) und relativ fixem i7 lasse ich das Ding zur not abends loskompilieren... Das ist ja nix, was ich im aktuellen Tagesgeschäft brauche... Ich sehe keinerlei Nachteile darin, nur Vorteile: Wenn das Teil durchkompiliert, dann kann ich sicher sein, dass ALLES funktioniert, weil alle benötigten Libs da sind... Und ich hab halt wirklich nur das nötigste und dank ssd innerhalb 1-2 sek ein officepaket laufen... Aber so ist das mit allem unter gentoo: minimal aber voll funktional... Ich hab z.B. auch auf dem Desktop Rechner nur ca. 10 Dienste laufen, genügt... Das hab ich bei xbuntu schon in der minimal install

        1
        Von openWeb am Mo, 2. Oktober 2017 um 00:07 #

        Als Gentoo-User: LibO brauche ich regelmäßig... Mein Rechner läuft 24/7... Warum also sollte mich ein Update von 1,5h stören? Dank 32GB Ram (war billig) und relativ fixem i7 lasse ich das Ding zur not abends loskompilieren... Das ist ja nix, was ich im aktuellen Tagesgeschäft brauche... Ich sehe keinerlei Nachteile darin, nur Vorteile: Wenn das Teil durchkompiliert, dann kann ich sicher sein, dass ALLES funktioniert, weil alle benötigten Libs da sind... Und ich hab halt wirklich nur das nötigste und dank ssd innerhalb 1-2 sek ein officepaket laufen... Aber so ist das mit allem unter gentoo: minimal aber voll funktional... Ich hab z.B. auch auf dem Desktop Rechner nur ca. 10 Dienste laufen, genügt... Das hab ich bei xbuntu schon in der minimal install

        1
        Von openWeb am Mo, 2. Oktober 2017 um 00:07 #

        Als Gentoo-User: LibO brauche ich regelmäßig... Mein Rechner läuft 24/7... Warum also sollte mich ein Update von 1,5h stören? Dank 32GB Ram (war billig) und relativ fixem i7 lasse ich das Ding zur not abends loskompilieren... Das ist ja nix, was ich im aktuellen Tagesgeschäft brauche... Ich sehe keinerlei Nachteile darin, nur Vorteile: Wenn das Teil durchkompiliert, dann kann ich sicher sein, dass ALLES funktioniert, weil alle benötigten Libs da sind... Und ich hab halt wirklich nur das nötigste und dank ssd innerhalb 1-2 sek ein officepaket laufen... Aber so ist das mit allem unter gentoo: minimal aber voll funktional... Ich hab z.B. auch auf dem Desktop Rechner nur ca. 10 Dienste laufen, genügt... Das hab ich bei xbuntu schon in der minimal install

        1
        Von openWeb am Mo, 2. Oktober 2017 um 00:07 #

        Als Gentoo-User: LibO brauche ich regelmäßig... Mein Rechner läuft 24/7... Warum also sollte mich ein Update von 1,5h stören? Dank 32GB Ram (war billig) und relativ fixem i7 lasse ich das Ding zur not abends loskompilieren... Das ist ja nix, was ich im aktuellen Tagesgeschäft brauche... Ich sehe keinerlei Nachteile darin, nur Vorteile: Wenn das Teil durchkompiliert, dann kann ich sicher sein, dass ALLES funktioniert, weil alle benötigten Libs da sind... Und ich hab halt wirklich nur das nötigste und dank ssd innerhalb 1-2 sek ein officepaket laufen... Aber so ist das mit allem unter gentoo: minimal aber voll funktional... Ich hab z.B. auch auf dem Desktop Rechner nur ca. 10 Dienste laufen, genügt... Das hab ich bei xbuntu schon in der minimal install

        1
        Von openWeb am Mo, 2. Oktober 2017 um 00:07 #

        Als Gentoo-User: LibO brauche ich regelmäßig... Mein Rechner läuft 24/7... Warum also sollte mich ein Update von 1,5h stören? Dank 32GB Ram (war billig) und relativ fixem i7 lasse ich das Ding zur not abends loskompilieren... Das ist ja nix, was ich im aktuellen Tagesgeschäft brauche... Ich sehe keinerlei Nachteile darin, nur Vorteile: Wenn das Teil durchkompiliert, dann kann ich sicher sein, dass ALLES funktioniert, weil alle benötigten Libs da sind... Und ich hab halt wirklich nur das nötigste und dank ssd innerhalb 1-2 sek ein officepaket laufen... Aber so ist das mit allem unter gentoo: minimal aber voll funktional... Ich hab z.B. auch auf dem Desktop Rechner nur ca. 10 Dienste laufen, genügt... Das hab ich bei xbuntu schon in der minimal install

0
Von jhohm am Fr, 29. September 2017 um 14:56 #

... warum auch?
Wenn eine Applikation ausgereift ist, wird sie meistens ziemlich zeitnah als Paket angeboten...
Als Debian-User wäre das evtl anders, aber bei Ubuntu kann ich da etwas warten...

0
Von Unerkannt am Fr, 29. September 2017 um 16:06 #

Zuletzt diese Woche. Ich wollte mir einmal Pine anschauen und der Paketmanager hätte mir einige Abhängigkeiten in das System gezogen, die ich nicht drauf haben möchte. Beim Selbstkompilieren waren keine zusätzlichen Abhängigkeiten zu erfüllen gewesen.

0
Von Unerkannt am Fr, 29. September 2017 um 16:07 #

Zuletzt diese Woche. Ich wollte mir einmal Pine anschauen und der Paketmanager hätte mir einige Abhängigkeiten in das System gezogen, die ich nicht drauf haben möchte. Beim Selbstkompilieren waren keine zusätzlichen Abhängigkeiten zu erfüllen gewesen.

0
Von sbsjsjsjs am Fr, 29. September 2017 um 16:31 #

Ein paar mal im Jahr. Wenn Debian kein Paket anbietet oder wenn es keine kompatible Binary gibt.

Bei vielen Anwendungen ist es unmöglich. Es gibt in C kein standardisiertes Buildsystem. In Java ebenfalls nicht. Man ist stundenlang damit beschäftigt die schlechte oder nicht vorhandene Doku nachzuvollziehen.

Die Makefiles sind meist beschissen und nur auf den Rechner des Devs zugeschnitten. Viele Pfade sind absolut. Abhängigkeiten sind dann meist unfrei oder nicht Dokumentiert. Meist merkt man es erst wenn der Compiler oder Linker meckert.

Dann kommen die 1337 h0m3br3w Hacker auf die Idee Structs selber zu alignen, so dass später noch eine Runtime Hölle zu erwarten ist. Das jahrelange Lernen und Klpieren aus Stack Overflow hinterlässt eben seine Spuren.

Es lohnt sich so gut wie nie selbst zu kompilieren. Professionelle Anwendungen sind meist schon optimiert, man gewinnt also nicht an performance. Im Bereich Open Source gibt es nur wenige Beispiele mit hervorragender Codequalität und die kommt meistens von größeren Firmen.

  • 0
    Von Anonymous am Fr, 29. September 2017 um 17:54 #

    Ja, Pakete bauen auf debian ist die Hölle. Das stimmt, alles was du da oben erwähnt hast, fast alles. Eins hast du unterschlagen, vergiss nicht die doofen *-dev Pakete als Abhängigkeit zu installieren bevor Du zu bauen anfängst.

    Debian ist als compile host total daneben +1

0
Von Anonymous am Fr, 29. September 2017 um 16:33 #

Das waren aber nur ein paar Slackbuilds.

0
Von Alter Sack am Fr, 29. September 2017 um 17:27 #

Anders bekommt man heutzutage schwer ein brauchbares System.

  • 0
    Von sbsjsjsjs am Fr, 29. September 2017 um 17:33 #

    So? Was genau willst du denn besser können als der Dev selbst?

    • 0
      Von Alter Sack am Fr, 29. September 2017 um 20:35 #

      Was hat denn deiner Meinung nach Kompilieren mit Entwickeln zu tun?

      • 0
        Von sbsjsjsjs am Fr, 29. September 2017 um 20:52 #

        Die meisten Devs stellen auch kompilierte Pakete zur Verfügung. Sie erstellen auch Makefiles.

        Meine Frage hast du nicht beantwortet, was soviel heißt, dass du wie jeder andere Kompilierer, nichts anpasst. Dann kannst du auch das vorkompilierte Paket nehmen und dir die Mühe sparen.

        Veränderungen am Build Prozess (Optimierung, Abhängigkeit, Prozessor Architektur) ist ohnehin nicht sinnvoll wenn man nicht aktiv am Projekt mitarbeitet.

        • 0
          Von Alter Sack am Fr, 29. September 2017 um 21:36 #

          Halt mal bitte den Ball flach, okay? Ich muss mich nicht rechtfertigen, was ich mit mit freiem Code mache, solange es der Lizenz entspricht. Ich muss auch keine Unterstellungen beantworten. Ich habe freie Software immer so begriffen, dass ich mit dem Code alles machen darf, was die Lizenz erlaubt. Ich werde auf das, was ich unter "brauchbares System" verstehe, auch nicht weiter eingehen.

          Veränderungen am Build Prozess (Optimierung, Abhängigkeit, Prozessor Architektur) ist ohnehin nicht sinnvoll wenn man nicht aktiv am Projekt mitarbeitet.

          Okay, mal ein unverfängliches Beispiel: Ich dürfte deiner Meinung nach also nicht xu4 , ein freies Remake von Ultima IV, für ARM kompilieren, weil ich nicht aktiv am Projekt mitarbeite?

          • 1
            Von Verfluchtnochmal am Sa, 30. September 2017 um 00:21 #

            Ja was denn - Benenne deine Probleme oder halte das Maul!

            du bist doch nur genauso ein Versager wie die paar schreihälse die sich dauernd über systemd beschweren dabei so klingen wollen als wären sie die Mehrheit und ausser "alles anders, zu dumm und zu faul" keine Argumente vorbringen ausser dass der Schwager vom Halbbruder auch sagt

            Läuft @home als systemwide systemd-unit seit die Maschine 2011 aufgesetzt wurde 24 Stunden am Tag ohne Zucker

            Da waren von Fedora 15 bis 25 auch 10 Dist-Upgrades dabei

            Läuft auf der workstation im Büro genauso lange, streng genommen ein paar Jahre länger aber dazwischen Neuinstallation, seit dem wandert das software raid samt OS auf neue Hardware mit

          0
          Von Gitstompah am Sa, 30. September 2017 um 09:24 #

          Meine Frage hast du nicht beantwortet, was soviel heißt, dass du wie jeder andere Kompilierer, nichts anpasst. Dann kannst du auch das vorkompilierte Paket nehmen und dir die Mühe sparen.

          Richtig, könntest du, wenn es den vorkompiliertes Paket gäbe. Der "Kompilierer" oder Dev stellt aber nicht unbedingt für jedes Paketmanagementsystem und/oder Architektur ein Paket bereit. Die Distributoren sind teilweise auch etwas langsam, wenn es neuere Versionen gibt, wenn sie den das Paket überhaupt updaten.

          Veränderungen am Build Prozess (Optimierung, Abhängigkeit, Prozessor Architektur) ist ohnehin nicht sinnvoll wenn man nicht aktiv am Projekt mitarbeitet.

          Unsinniger geht es nicht mehr, oder?

          • 0
            Von sbsjsjsjs am Mi, 4. Oktober 2017 um 17:19 #

            > Unsinniger geht es nicht mehr, oder?

            Es ist schon erstaunlich wie viel Halbwissen hier herrscht und wie wehement solche Leute ihre Meinung verteidigen.

            Bei Firefox führte der Switch auf 64 Bit lange für kaputte Binaries, weil der obere Bit Bereich der longs? zum Speichern der Meta Informationen verwendet wurde.

            Bei PCL führt Änderungen am Struct Alignment regelmäßig zu korruptem Speicher, weil intern selbst optimiert wird.

            Einstellungen wie -O3, das Hinzuschalten von AVX oder OpenMP optimiert hin und wieder zu aggressiv, so dass die Programme aufgrund von z. B. Thread Racing langsamer laufen als mit (nur) O2.

            So viel zum Thema Unsinn den du selbst verbreitetst.

    0
    Von jhohm am Fr, 29. September 2017 um 19:58 #

    "Anders bekommt man heutzutage schwer ein brauchbares System."
    -------------------------------------------------Zitatende---------------

    Gewagte Theorie...
    Das würde bedeuten, das
    a.die Maintainer in den Distris unfähig sind
    und b. das die User like me schlauer als die Maintainer sind.

    Ich denke, da trollt nur jemand rum.

    • 0
      Von Alter Sack am Fr, 29. September 2017 um 20:59 #

      Gewagte Theorie...
      Die lese ich eigentlich nur bei dir. Deine Schlussfolgerungen sind haltlos.
      Mal schauen, ob du mir folgen kannst: Andersherum wird nämlich ein Schuh daraus. Ein Maintainer, der sich exakt den individuellen Befindlichkeiten eines Nutzers anpasst, ist – ganz genau – ein schlechter Maintainer. Es verhält sich also genau andersherum, als von dir postuliert. Deine weiteren Folgerungen sind somit auch zu vernachlässigen. Alles klar soweit?

      Gut. Entwickler A entwickelt die Anwendung foo und nimmt dort nach reiflicher Überlegung die Funktionalität bar auf. Der Maintainer B der Distro X baut das Paket nun standardmäßig mit der Funktionalität bar, ebenfalls nach reiflicher Überlegung. User Y hat aber nun einen anderen Use-Case für foo, kann aber mit der Funktionalität bar leben. User Z hingegen hat einen ähnlichen Use-Case wie Y, mag aber nach reiflicher Überlegung die Funktionalität bar nicht haben. Weil es sich nun um freie und quelloffene Software handelt, baut Z sein eigenes Paket, was auch ganz einfach ist, da A eigens dafür vorgesehen hat, foo wahlweise ohne bar zu kompilieren. Z lädt sein Paket foo-without-bar ins User-Repo seiner Distro hoch. Y freut sich darüber und bedankt sich bei Z. Beide sind froh, dass A die Funktionalität von bar fakultativ aufgenommen hat. Was ist mit A? Der freut sich auch, dass ihm Z ein paar Nörgler vom Hals hält. Alles klar soweit?

      0
      Von Gitstompah am Sa, 30. September 2017 um 09:33 #

      Die sind nicht unfähig, aber es ist einfach nur dämlich jede Anwendung "distributionsbahängig" zu bauen.

      IMHO haben sich die distributionsabhängigen Repositories komplett überholt. Da wird viel zuviel Aufwand dafür verbraten. Bevor ich mir den Abhängigkeitswahn antue, baue ich manche Anwendung lieber komplett selbst aus dem Source.

      • 0
        Von comandor am Mo, 2. Oktober 2017 um 19:03 #

        >IMHO haben sich die distributionsabhängigen Repositories komplett überholt. Da wird viel zuviel Aufwand dafür verbraten.
        Dies.
        In Zeiten mit 100 Nutzeranwendungen war das vielleicht mal praktikabel.

      0
      Von immoreofaKDEusermyself am Mo, 2. Oktober 2017 um 19:19 #

      "Das würde bedeuten, das
      a.die Maintainer in den Distris unfähig sind"
      ------------------------------Auszug Ende-------------

      Schau doch mal, wie wenig Distributionen wirklich in der Lage sind, KDE oder etwas anderes hinreichend Funktionales mit der entsprechend benötigten Komplexität funktionierend abzuliefern.
      Selbst bei den meisten großen Distributionen hapert es an allen Ecken und Enden.
      Wenn ihr mal wieder jemanden über KDE-Bugs jammern hört, sollte man wirklich erstmal prüfen ob das nicht mal wieder ein Fehler der Distributoren war.
      KDE ist hier nur ein Beispiel, weil man Aufgrund der recht homogenen Nutzfläche garantiert auf das ein oder andere faux pas stößt.
      Es gibt natürlich noch andere Stellen, wo sich die Überforderung der Distributoren bemerkbar macht.

      Das es viele Maintainer gibt, die irgendwelche simplen Serverdistributionen paketieren und zuverlässig mit Updates können bestreitet hier sicherlich niemand, aber das ist nunmal leider nicht der Maßstab für Desktopnutzer.

0
Von yxcvbnm am Fr, 29. September 2017 um 18:02 #

Für EOL-Distros besteht mitunter die Notwendigkeit, eine "Fremdanwendung" zu kompilieren.

Falls so ein LTS-Kernel von kernel.org als solche "Fremdanwendung" zählt, dann habe ich vor kurzem eine kompiliert, nämlich Kernel 3.2.93 für Debian Squeeze. Gerade der Kernel ist da noch eines der reibungslosesten und einfachsten Updates.

0
Von Holla die Waldfee am Fr, 29. September 2017 um 22:50 #

Ich nutze mittlerweile eine eher konservative Distribution, diese deckt aber alle meine (Software-) Bedürfnisse gut ab. Lieber etwas "abgehangen", aber dafür stabil.

Sehr aktuelle Programmversionen teste ich ab u. zu in virtueller Umgebung.

0
Von who knows am Sa, 30. September 2017 um 11:42 #

- Aktueller Kernel wegen aktueller Hardware
Den aktuellsten Kernel kann man auch aus
einem Repo installieren, aber der ist dann nicht
„abgespeckt“.

- Multimediaanwendungen, wegen Patentkeule.

- Anwendungen und Bibliotheken, die nicht oder
nicht in der gewünschten Version als Paket
verfügbar sind.

Die meisten Anwendungen oder Bibliotheken nutzen ein Buildsystem wie automake/autoconf, cmake oder scons. Man sollte sich aber vor dem Build erst einmal die Dokumentation durchlesen, da dort oft die Abhängigkeiten aufgelistet sind und dann die dazu passenden Entwicklerpakete installieren. Auch kann es vorkommen, dass der Build wegen nicht erfüllter Abhängigkeiten abbricht. Die Fehlermeldungen geben dann Aufschluss über fehlende Bibliotheken. Als Anfänger benötigt man dazu allerdings erst einmal etwas Geduld. Mit ein wenig Übung funktioniert es dann relativ Problemlos.

who knows

0
Von Tuxentier2011 am Sa, 30. September 2017 um 16:51 #

Klar, bei Gentoo ist kompilieren häufig, allerdings ist es da auch recht bequem eingerichtet.
Außerhalb vom portage tree (oder overlays) mache ich das selten. Hier _kann_ man schnell an Grenzen stoßen, vor allem, wenn das nicht gut dokumentiert ist. Ein paar mal habe ich irgendwelche kleinen Sachen übersetzt, mal einen Grafiktreiber. Mich einmal an einem Kernelmodul bzw. Kernelpatch versucht und es aufgegeben (aber auch festfestellt, daß das wohl nur bis 2.6. ... hmm... 19??? funktioniert hätte. Danach ging es eh nicht mehr. Hätte ich also coding-skills gebraucht, um den SATA-Treiber umzubasteln, damit er mit 3.x oder 4.x läuft. Tja, hatte ich nicht. Und merkwürdigerweise hat es bis dato scheinbar auch sonst keiner versucht oder zumindest nie upstream geschickt.
(Kauft keine Marvell-Chips!)

0
Von Mal im Gedächtnis gekramt am Sa, 30. September 2017 um 20:58 #

Hallo,

ich habe tatsächlich eine Anwendung mal wieder selber kompiliert. Ich wollte die neue Version von OpenRA testen, weil ein par Kumpels ein Spiel zum zocken suchten. Also Sources von Github geklont und kompiliert. Lief sauber durch und hat wunderbar funktioniert. Generell, hab ich gute Erfahrungen beim Kompilieren von Spielen gemacht. Warzone2100 kompilierte auch immer sauber durch. Sollten doch mal Bibliotheken gefehlt haben, waren diese schnell nachinstalliert.

0
Von Mal im Gedächtnis gekramt am Sa, 30. September 2017 um 20:58 #

Hallo,

ich habe tatsächlich eine Anwendung mal wieder selber kompiliert. Ich wollte die neue Version von OpenRA testen, weil ein par Kumpels ein Spiel zum zocken suchten. Also Sources von Github geklont und kompiliert. Lief sauber durch und hat wunderbar funktioniert. Generell, hab ich gute Erfahrungen beim Kompilieren von Spielen gemacht. Warzone2100 kompilierte auch immer sauber durch. Sollten doch mal Bibliotheken gefehlt haben, waren diese schnell nachinstalliert.

0
Von Proultrahyperpowergamer am So, 1. Oktober 2017 um 11:14 #

Was manche Distros an aktuellen Spielen haben ist ja oft nicht so toll und bei kleineren Spielen wie C-Dogs gibt es halt keine nächtlichen Builds.

0
Von mdosch am Mo, 2. Oktober 2017 um 10:11 #

Auf meinen Rechnern seltener aber häufig auf meinem Webspace da ich dort prosody 0.10 master und tor laufen habe und die selbst kompilieren muss. Einige Abhängigkeiten wie z.B. libevent und OpenSSL habe ich auch kompilieren müssen, da sie bei CentOS6 veraltet waren.

Auf meinen eigenen Rechnern kompiliere ich mittlerweile recht selten, da fast alles in Debian Quellen enthalten ist was ich brauche/möchte.

Auf meinem Netbook habe ich mir ab und an mal ein Backport von testing gebaut wenn Pakete nicht in stable vorhanden oder veraltet waren. Das netbook nehme ich mit auf Reisen wo ich teilweise schlechte Internetverbindung habe, deshalb ist mir da die Menge an Updates in testing zu hoch.

Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten