Anzeige:
Ergebnis 1 bis 3 von 3

Thema: Installation von Software aus Quellarchiven

  1. #1
    Registrierter Benutzer Avatar von Ulli Ivens
    Registriert seit
    Jan 2001
    Ort
    Heinsberg im Rheinland, Deutschland
    Beiträge
    1.844

    Post Installation von Software aus Quellarchiven




  2. Zu dieser FAQ

  3. Allgemein

  4. Entpacken der Archive

  5. Installation

  6. Deinstallation

  7. Troubleshooting

  8. Dokumentation

  9. Lizenz











  10. Zu dieser FAQ



    Dieser Abschnitt der FAQ soll die Installation von Software unter Linux aus
    Quellarchiven, sogenannten "Tarballs" verdeutlichen. Er
    soll grundsätzliche Hilfe zu Problemen und Fehlermeldungen geben
    und verdeutlichen wie die Konfiguration und Installation grob
    funktioniert. Primär angesprochen werden Linuxneulinge und noch
    nicht so erfahrende Linux - Anwender.












    Allgemein



    Quellarchive liegen in der Regel als folgende Dateien vor, jenachdem welcher Packalgorithmus vom Verfasser
    des Paketes verwendet wurde.


    - tar (unkomprimiert),

    - tar.Z,

    - tar.gz oder tgz, was das selbe ist,

    - tar.bz2


    In Tarballs steht der reine Quellcode welchen man mit den entsprechenden Kenntnissen der jeweiligen
    Programmiersprache leicht verifizieren kann oder bei Bedarf und endsprechender Lizenz unter der die
    Software veröffentlicht wurde ändern/erweitern kann. Der gleiche Tarball kann auf verschiedenen
    UNIX - Derivaten compiliert werden. Dadurch wird der Autor der Software davor bewart, verschiedene Versionen
    zu schreiben.












    Entpacken der Archive



    Bevor man irgendwas machen kann muss man das Quellarchive erst mal entpacken. Das kann man mit Linux - Bordmitteln
    leicht erledigen. Die folgenden Beispiele verdeutlichen für ein unkomprimiertes tar-Archiv und die jeweiligen Packalgorithmen die
    Vorgehensweise auf der Shell:








    tar -xvf <Name>.tar


    tar -xvZf <Name>.tar.Z


    tar -xvzf <Name>.tar.gz


    tar -xvjf <Name>.tar.bz2




    Es kann auch sein das tar nicht mit bz2 Archiven arbeiten kann (bei älteren Linux Distributionen und anderen
    UNIX - Derivaten, die nicht über GNU/tar verfügen). Dann kann man diese Archive folgendermaßen
    über eine Pipeline entpacken:







    cat <Name>.tar.bz2 | bzip -d | tar xvf -

    bzcat <Name>.tar.bz2 | tar xv




    Informationen zu tar, gzip und bzip2 findet man in der entsprechenden ManPage die man sich
    unbedingt zu Gemüte führen sollte !! Es gibt auch noch sogenannte share files (auch Shell Archive genannt). Diese kommen
    häufig in den Newsgroups vor. Näheres dazu im
    Software-Building-HOWTO
    . Dort steht auch noch einiges Interessante zum Patchen von Quellpaketen und wie man Pakete in
    anderen Formaten wie arj, zip, lha, zoo, rar, shk oder arc behandelt.












    Installation



    Das Quellarchiv hat sich sich in ein Verzeichnis entpackt und man kann jetzt schon fast loslegen! Aber wie ??
    Jetzt kommt die in den Quellarchiven IMMER1 vorhandene Dokumentation ins Spiel... Ohne die geht gar nichts !!
    Dokumentation liegt meistens in den Dateien README und/oder INSTALL als Textfile vor das mit jedem Editor zu öffnen ist.
    Meistens ist auch noch ein Unterverzeichnis doc/ da, in dem Dokumentation als html -File oder erweiterte Dokumentation als
    Textfile zur Verfügung steht. Lesen dieser Dokumentationen kann ich jedem nur ans Herz legen. Viele Fragen lassen sich
    damit schon von vornherein aus dem Weg räumen. Auch befinden sich noch andere Dateien in den Verzeichnissen, auf die
    man mal einen Blick mit dem Texteditor werfen sollte. Ich denke da so an das Makefile etc. Man kann dadurch nur lernen.








    1
    Das stimmt leider nicht immer, es gibt auch Quellen die wenige oder gar keine Angaben zur Installation oder der Compilierung
    enthalten, z.B. CVS - Versionen neuester Software oder von Beta Versionen, bei denen die ProgrammiererInnen noch keine
    Dokumentation geschrieben haben.



    Der Idealfall - oder die "GNU-autoconf"-Konforme Installation:



    Bei kleineren Softwarepaketen handelt es sich oft um eine "GNU-autoconf"-Konforme Installation. Man wechselt in das Verzeichnis
    das aus dem entpackten Tarball entstanden ist. (Wenn man sich nicht schon längst darin befindet, denn eigentlich sollte man
    ja schon die Dokumentation gelesen haben ! )
    Mit den folgenden Befehlen erzeugt man aus dem Quellcode des Tarballs das/die Binaries
    ( sozusagen den ausführbaren Programmcode ). Das ist jedoch wirklich nur Idealfall (!!!) der nicht immer zutreffen muss.
    Fehlermeldungen (bei ./configure oder make) die auftauchen können, werden im Troubelshooting - Abschnitt noch behandelt.









    ./configure

    Script das überprüft ob alle Voraussetzung für die Compilierung erfüllt sind

    make

    die eigentliche Compilierung, d.h. Erzeugung des ausfürbaren Programmcodes

    make install

    die eigentliche Installation - in der Regel als root ausgeführt


    Wenn alles funktioniert hat und man das compilierte Programm getestet hat kann man die erzeugten Binaries (im Quellverzeichnis)
    mit make clean löschen um Festplattenplatz zu sparen. Das compilierte Programm kann sofort benutzt werden.
    Ferner ist oft make check (Aufruf unmittelbar nach make) zur Kontrolle ob alles gut gegangen ist vorhanden. Durch einen Blick
    in das Makefile und/oder die Dokumentation kann man sehen welche Optionen bei make zur Verfügung stehen !!



    Das Makefile (erzeugen) und make Benutzen:



    Das Makefile ist der Schlüssel zum gesammten Compilierungsprozess. In der einfachsten Form ist das Makefile ein Shellscript
    um einen Tarball zu compilieren. Es kann aber potenziell noch viel mehr was den Rahmen dieses FAQ - Beitrages erheblich
    sprengen würde. Wer daran Interesse hat kann sich im Internet dazu mehr Informationen beschaffen.


    Um das Software - Building - HOWTO zu zitieren:

    An manchen Punkten startet das Makefile cc oder gcc. Das sind ein Präprozezzor, ein C (oder C++) Compiler und ein Linker.
    Dieser Prozess konvertiert die Quellpakete in die ausfu"rbaren Binaries.


    Das Makefile könnte man theoretisch auch weglassen, aber um ein Programm zu compilieren müsste man denn jede Datei
    des Quellcodes manuell übersetzen:
    Das folgende Beispiel ist nur eine Datei und ein größeres Programm hat hunderte davon:






    gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include -DNEED_GNOMESUPPORT_H -D_FILE_OFFSET_BITS=64
    -D_LARGEFILE_SOURCE -I/opt/gnome/include -I/opt/gnome/lib/gnome-libs/include -I/usr/X11R6/include
    -I/usr/include/glib-1.2 -I/usr/include/gtk-1.2 -I/usr/include/python2.1 -I/usr/lib/glib/include -I/usr/lib/perl5/5.6.1/i586-linux/CORE
    -I/usr/local/include -O2 -Wall -fno-strict-aliasing -g -pipe -c urlgrab.c


    Das man sich dabei leicht vertun kann und/oder wahnsinnig wird liegt auf der Hand Im Makefile wird das alles geschickt über
    Variablen etc. gelöst, so das das erstellen (bei ganz kleinen Softwarepaketen) nicht wirklich viel Arbeit ist ( wenn man es verstanden
    hat )
    Nur sehr einfache Software kommt wie gesagt mit einem einfachen, durch die Autoren erstellten, Makefile aus. Komplexere Software,
    die Zugriff auf die verschiedensten Bibliotheken (Librarys) braucht, benötigt ein "dynamisches" Makefile oder ein Shellscript
    welche sich individuell an das System anpasst. Hier kommen 2 Möglichkeiten in Frage:




    1. Das Imakefile ist sozusagen ein "temporäres" Makefile. Es besteht aus Makrofunktionen und erstellt mit
      Hilfe von Imake das Makefile, aus dem mit make dann anschließend die Binaries erstellt werden.
      Dazu ein Auszug aus der man - page von Imake:


      This allows machine dependencies (such as compiler options, alternate command
      names, and special make rules) to be kept separate from the descriptions of the various items to be built. -


      Das soll es zum Imakefile gewesen sein, man trifft es IMHO eher selten an.




    2. Das uns schon bekannte configure Script ist ein Shellscript das über bestimmte Systemvariablen
      und selbstdefinierte Variablen das/die Makefile(s) erzeugen läßt/lassen. Configure kann man auch
      Informationen übergeben, wenn zum Beispiel die ein oder andere benätigte Bibliothek nicht
      automatisch gefunden wird (siehe Abschnitt Troubelshooting). In der Regel sucht es sich selbst unter
      Zuhilfenahme von der Datei /etc/ld.so.cache die richtigen Pfade zu den Bibliotheken. Ferner hat man auch
      die Möglichkeit anzugeben ob die Binaries statisch oder dynamisch gelinkt werden sollen. Gelinkt bedeutet,
      das der Programmcode der Bibliotheken nicht fest in die zu erstellenden Binaries einkompiliert wird.
      Dies hat den Vorteil, dass der ausführbare Programmcode schneller und auch natürlich viel kleiner
      ist. Statisch heisst, dass der Programmcode der Bibliotheken fest in die Binaries des Programms kompiliert wird.
      Ein Beispiel für ein statisches Programm ist der Netscape - Browser. Er ist deswegen so groß und träge.
      (Anmerkung : Die statische Linkung von Netscape hat lizenzrechtliche Gründe). Es bietet auch noch die Möglichkeit
      sogenanntes cross-compiling vorzubereiten. d.h. auf einem Intel System zum Beispiel ein Programm zu kompilieren,
      das nacher auf einer Sparc - Workstation laufen soll oder sogar auf Windows. Für letzteres ist der lame mp3 Codec
      ein gutes Beispiel - den kann man unter Linux auch prima für Windows kompilieren.












    Deinstallation



    Damit man die Software wieder sauber deinstallieren kann gibt es verschiedene Möglichkeiten.


    make uninstall:


    Eher selten ist im Makefile von den Autoren eine Uninstall - Routine enthalten. In diesen Fällen reicht ein
    <make uninstall> aus. Die installierten Binaries und Dokumentationen werden dann geläscht. Im
    Zweifelsfall kann man das Makefile nach dieser Option untersuchen oder einfach mal ausprobieren.


    Checkinstall:


    Das Tool checkinstall von Felipe Eduardo Sanchez und Diaz Duran kann bei der Installation das make install ersetzen,
    es dürfte allen modernen Linux - Distributionen beiliegen. Es erzeugt RPM- oder Slackware - Packete die nach Erstellen dann
    automatisch eingespielt werden. Bei rpm - basierten Distributionen (z.B. SuSE oder RedHat ) kann mit dem bekannten rpm - Befehl
    und den entsprechenden Optionen (rpm -e ) das Paket jederzeit wieder sauber deinstalliert werden. Das erstellte rpm - Paket wird
    auch unter /usr/src/packages/RPMS und der jeweiligen Rechnerarchitektur (i386, i686 etc ) kopiert und kann danach natürlich
    wie jedes beliebige rpm - Paket behandelt werden.
    Für nähere Informationen über checkinstall bitte die README des Paketes lesen, darin enthalten ist eine
    detailierte Anleitung, mögliche Funktionen und auch die Anleitung zum Erstellen von Slackware - Paketen. Das Debian
    Paketformat soll in den nächsten Versionen von checkinstall auch unterstützt werden.



    Installation in ein temporäres Verzeichnis:


    Auch das ist eine Möglichkeit die man benutzen kann um Software aus Tarballs nacher wieder sauber zu Deinstallieren.
    Ziel des temporären Verzeichnisses ist es, eine Liste der installierten Dateien zu erstellen, anhand derer man dann
    später das Programm wieder entfernen kann. Die Frage ist nur, wie man das Programm in das Verzeichnis
    bekommt. Dazu sollte man wissen, dass man alle Optionen von configure auch make übergeben kann, d.h.
    die simpelste Lösung ergibt sich dann, wenn ein configure vorhanden ist. Für Pfadangaben stellt configure
    meist folgende Optionen zur Verfügung:








     
    ...
    --prefix=PREFIX

    --exec-prefix=EPREFIX

    --bindir=DIR
    --sbindir=DIR
    --libexecdir=DIR
    --datadir=DIR

    --sysconfdir=DIR
    --sharedstatedir=DIR

    --localstatedir=DIR
    --libdir=DIR
    --includedir=DIR
    --oldincludedir=DIR
    --infodir=DIR
    --mandir=DIR
    --srcdir=DIR
    ...
     
    install architecture-independent files in PREFIX
    [/usr/local]
    install architecture-dependent files in EPREFIX
    [same as prefix]
    user executables in DIR [EPREFIX/bin]
    system admin executables in DIR [EPREFIX/sbin]
    program executables in DIR [EPREFIX/libexec]
    read-only architecture-independent data in DIR
    [PREFIX/share]
    read-only single-machine data in DIR [PREFIX/etc]
    modifiable architecture-independent data in DIR
    [PREFIX/com]
    modifiable single-machine data in DIR [PREFIX/var]
    object code libraries in DIR [EPREFIX/lib]
    C header files in DIR [PREFIX/include]
    C header files for non-gcc in DIR [/usr/include]
    info documentation in DIR [PREFIX/info]
    man documentation in DIR [PREFIX/man]
    find the sources in DIR [configure dir or ..]




    Man sieht hier sehr schön, dass nur --prefix von Bedeutung ist, da alle anderen Pfadangaben --prefix als
    Ausgangspunkt nehmen, d.h. wollen wir das Programm temporär nach /tmp/<Name>/ installieren, geht das
    folgendermaßen :






    make prefix=/tmp/<Name>/usr/local/ install




    Allerdings fehlen noch zwei wichtige Schritte. Vor dem Installieren sollte man das temporäre Verzeichnis erst erstellen und
    überprüfen, ob alle Dateien auch unterhalb dieses Verzeichnisses installiert werden. Dafür hat make
    eine nützliche Option : -n. Damit lassen sich alle Installationschritte anzeigen aber werden nicht ausgefürt.
    Sollten wider Erwarten z.B. die Manpages nicht unter /tmp/<Name>/usr/local/man/ sondern unter /usr/local/man/
    installiert werden, übergibt man make noch die Option mandir=/tmp/<Name>/usr/local/man/ und
    läßt sich erneut mit -n den Installationsablauf anzeigen. Wenn dann irgendwann alles passt, installiert man
    das Paket:






    mkdir /tmp/<Name>/

    make -n prefix=/tmp/<Name>/usr/local/ install | less

    make prefix=/tmp/<Name>/usr/local/ install




    Jetzt hat man alle Dateien in der gleichen Hierarchie unter /tmp/<Name>/usr/local/ wie nachher unter /usr/local/.
    Das einzige, was man jetzt noch tun muss, ist mittels find die Dateien aufzulisten, mit sed das temporäre
    Verzeichnis aus jedem Dateipfad zu "schneiden" und das Ganze in einer Datei zu speichern :






    find /tmp/<Name>/ ! -type d | sed -e 's|/tmp/<Name>||' \

    >> <Name>-<Version>.liste



    Der Name und die Endung der Dateiliste ist beliebig, allerdings ist eine Bezeichnung nach Name und Version IMHO sinnvoll.
    Die Dateiliste speichert man da, wo man sie später bei der Deinstallation wieder findet ;-)

    Zum Schluß noch das Paket mittels make install in das richtige Verzeichnis installieren und das temporäre
    mittels rm -rf /tmp/<Name>/ entfernen.



    Um das Paket später zu deinstallieren, benötigt man noch folgendes Script, dass man z.B. unter /sbin/uninstall
    speichert :





     
    #!/bin/sh

    if [ -f "$1" ]; then
    for file in $(cat "$1"); do
    rm -v $file 2>/dev/null
    done
    else
    # Dateiliste exisitiert nicht
    echo "Benutzung: $0 <Dateiliste>"
    exit 1
    fi

    exit 0















    Troubleshooting





    • Fehlermeldungen bei configure



      Bei Fehlermeldungen bei configure nicht sofort aufgeben, meist sind nur Kleinigkeiten die Ursache. Es gilt wie immer:
      Die Meldungen des configure - Scripts gründlich durchzulesen. Meistens ( wenn keine Vollinstallation des Linuxsystems
      gewählt wurde), sind fehlende Bibliotheken, Programme oder Header - Dateien ( das sind die devel - Pakete) die Ursache,
      die leicht durch einspielen der entsprechenden Pakete von der Distribution CD's/DVD beheben lassen.
      Anmerkung: Wenn man fehlende Bibliotheken selbst compilieren möchte muss die Datei /etc/ld.so.conf noch um das
      Installationsverzeichnis der entsprechenden Bibliothek ergänzt werden und ldconfig ausgeführt werden.
      Das sollte man auch tun wenn die Bibliothek auf dem System vorhanden ist und trozdem nicht erkannt wird.



      Oft ist ein Fehlschlag bei configure auch dadurch begründet, das schlicht die Verzeichnisvariablen falsch gesetzt sind.
      Man hat die Möglichkeit, sich mit env oder export die aktuell exportierten Shellvariablen anzeigen zu lassen
      und zu vergleichen, ob diese richtig gesetzt sind. Falls nicht, exportiert man sie einfach neu. Beispiel:






      export KDEDIR=/opt/kde2




      Man kann dies auch dauerhaft in der Datei /etc/profile oder /etc/profile.local eintragen.
      Oft tauchen auch Fehlermeldungen auf obwohl alle Bibliotheken etc. vorhanden sind aber configure sie nicht automatisch
      finden kann. Falls das der Grund ist kann man configure mit ensprechenden Optionen starten. Mit ./configure --help
      bekommt man einen Überblick über die möglichen Optionen die je nach Art und Umfang des
      Quellpaketes erheblich differieren.


      Bevor man configure mit neuen Optionen erneut startet, sollte man erst die Datei config.cache löschen,
      da es sonst passieren kann, dass configure trotz richtiger Optionen fehlschlägt. In der besagten Datei
      wird nämlich das Ergebnis des letzten Durchlaufs gespeichert und eventuell bei einem erneuten Durchlauf direkt aus dieser
      Datei ( Cache ) übernommen.


      Das nun folgende Beispiel ist auch auf andere Bibliotheken/Toolkits übertragbar !!
      Als Beispiel dient ein Programm das auf das GTK ( GTK steht für GIMP- Tool Kit) zurückgreift. Die Programmierer habe
      damals nach einer Lösung gesucht, die Aufrufe in Sachen Grafik zu vereinfachen; dafür wurde das GTK
      geschrieben. Durch eine immer grässere Verbreitung des GTK basieren viele neue Programme darauf.
      Es macht jedoch trotz seiner Vereinfachungen für die Programmierung beim Kompilieren des öfteren Probleme.
      Um vor dem Kompilieren festzustellen, welche Version von GTK auf dem System vorhanden ist, sucht configure
      danach. Falls configure das GTK nicht findet (hier habe ich die Fehlermelung provoziert) erscheint eine solche
      Fehlermeldung :





       
      ....
      checking for gtk-config... /usr/local/bin/gtk-config
      checking for GTK - version >= 1.2.0... no
      ./configure: /usr/local/bin/gtk-config: Datei oder Verzeichnis nicht gefunden

      *** Could not run GTK test program, checking why...
      *** The test program failed to compile or link. See the file config.log for the
      *** exact error that occured. This usually means GTK was incorrectly installed
      *** or that you have moved GTK since it was installed. In the latter case, you
      *** may want to edit the gtk-config script: /usr/local/bin/gtk-config

      Cannot find GTK! Not building GTK FrontEnd.
      ...




      Dann ist die Vorgehensweise relativ simpel. Man sucht die Datei gtk-config (z.B. locate gtk-config) und merkt sich
      den Pfad dahin. Dann ruft man ./configure --help auf. Man bekommt dann eine solche Bildschirmausgabe:








       
      ...
      Features and packages:

      --disable-FEATURE
      --enable-FEATURE[=ARG]
      --with-PACKAGE[=ARG]
      --without-PACKAGE
      --x-includes=DIR
      --x-libraries=DIR
      --disable-nls
      --with-included-gettext
      --with-catgets
      --enable-debug
      --enable-socks
      --enable-openssl[=PATH]
      --enable-hebrew
      --enable-panel
      --enable-ipv6
      --disable-gtkfe
      --disable-textfe
      --disable-glib
      --disable-gnome
      --disable-zvt
      --disable-gdk-pixbuf
      --disable-xlib
      --disable-perl
      --disable-python
      --disable-plugin
      --disable-trans
      --with-glib-prefix=PFX
      --with-glib-exec-prefix=PFX
      --disable-glibtest
      --with-gtk-prefix=PFX
      --with-gtk-exec-prefix=PFX
      --disable-gtktest
       



      do not include FEATURE (same as --enable-FEATURE=no)
      include FEATURE [ARG=yes]
      use PACKAGE [ARG=yes]
      do not use PACKAGE (same as --with-PACKAGE=no)
      X include files are in DIR
      X library files are in DIR
      do not use Native Language Support
      use the GNU gettext library included here
      use catgets functions if available
      enable use of Memory Debug (default: no)
      enable use of SOCKS5 (default: no)
      enable use of openSSL (default: no)
      enable Hebrew support (default: no)
      enable gnome panel support (default: no)
      enable IPv6 (default: no)
      disable building gtk frontend
      disable building text frontend
      disable use of glib (implies --disable-gtkfe)
      disable use of gnome
      disable zvt/shelltab feature
      disable use of gdk-pixbuf
      disable use of xlib (for non X11 systems)
      disable use of perl scripting
      disable use of python scripting
      disable plugin support
      disable translation table support
      Prefix where GLIB is installed (optional)
      Exec prefix where GLIB is installed (optional)
      Do not try to compile and run a test GLIB program
      Prefix where GTK is installed (optional)
      Exec prefix where GTK is installed (optional)
      Do not try to compile and run a test GTK program




      Hieran sieht man mal wie umfangreich die Optionen bei configure sein kännen. Die Vorgehensweise ist relativ simpel.
      Erst löscht man die Cache - Datei (in der Regel config.cache). Man sucht dann die Datei gtk-config (z.B. locate
      gtk-config oder find / -name gtk-config ) und merkt sich den Pfad dahin. Dann ruft man configure mit der Option
      --with-gtk-prefix=/Pfad/zu/gtk-config auf :






      spookys:/usr/local/src/programme/xchat-1.8.4# rm config.cache

      spookys:/usr/local/src/programme/xchat-1.8.4# locate gtk-config

      /usr/bin/gtk-config

      /usr/share/man/man1/gtk-config.1.gz

      /usr/X11R6/bin/wxgtk-config

      spookys:/usr/local/src/programme/xchat-1.8.4# ./configure --with-gtk-prefix=/usr

      creating cache ./config.cache

      ......

      checking for gtk-config... /usr/bin/gtk-config

      checking for GTK - version >= 1.2.0... yes

      ......




      Nachfolgend sind häufige und meist hier im Forum gefundene Fehlermeldungen und deren Behebung aufgelistet:






      ./aclocal.m4:2181: error: m4_defn: undefined macro: _m4_divert_diversion



      ./configure: error: C/C++ compiler cannot create executables.



      ./configure: flex: command not found



      ./configure: lex: command not found







      ./aclocal.m4:2181: error: m4_defn: undefined macro: _m4_divert_diversion.

      Dieser Fehler tritt meist bei KDE-Programmen auf, die über CVS in Verbindung mit
      autoconf Version 2.52 kompiliert werden. Hier hilft nur ein Downgrade auf Version 2.13.




      configure: error: C/C++ compiler cannot create executables.

      Dieser Fehler tritt auf, wenn entweder kein Compiler installiert ist, oder die FLAGS falsch gesetzt sind.
      Ersteres dürfte aber kein Problem darstellen, da bei jeder Distribution ein Compiler vorhanden sein
      sollte. Der Name des Compiler-Pakete´s ist meist gcc oder egcs.
      Sollte der Compiler installiert sein, am Besten die Fehlermeldung von configure zusammen mit dem
      betreffenden Auszug aus der config.log im gleichen Verzeichnis hier im Forum posten.




      ./configure: flex: command not found

      Dir fehlt das Programm flex ( Fast Lexical Analyzer Generator ). Flex ist das freie Pendant zu lex und
      sollte auf den CDs Deiner Distribution vorhanden sein.




      ./configure: lex: command not found

      siehe flex





    • Fehlermeldungen bei make



      Ein Patentrezept für eine Lösung von Fehlern bei make gibt es leider nicht. Es kommt aber eigentlich sehr selten vor, dass
      bei stabiler gut getesteter Software nach einem erfolgreichen configure - Aufruf der make - Aufruf fehlschägt -
      wenn man Murphy mal außen vor lät

      Wird aber Beta Software ( ganz kleine Versionsnummern, CVS - Snapshots, etc ) verwendet, kommt es öfter vor das make
      mit einem Fehler abbricht. Da kann man als Linuxneuling oder noch nicht so erfahrener Benutzer (ohne Programmierkenntnisse) eigentlich
      nicht viel machen außer auf eine neue Version zu warten (was meißtens sehr schnell geht, da nicht nur du das Problem hast ).


      Nachfolgend sind häufige und meist hier im Forum gefundene Fehlermeldungen und deren Behebung aufgelistet:





      make: command not found







      make: command not found

      Das Programm make ist auf Deinem System nicht installiert.















    Dokumentation


















    Software-Building-Howto
     

    Eine weitere Anlaufstelle für Hilfe zum Kompilieren von Quellpaketen,
    allerdings auf englisch. Trotzdem ist die Seite auf alle Fälle einen Besuch wert


    Compiling and installing software from sources
     

    Ein nettes einfaches aber englisches Tutorial von IBM (http://www.ibm.com/developerworks/).
    Man muss sich kostenlos registrieren und hat zugriff auf jede Menge guter Tutorials !!













    Lizenz





    Dieser Beitrag steht unter der "GNU Free Documentation License GFDL" nachzulesen unter:
    http://www.gnu.org/copyleft/fdl.html








    Gruß Ulli

    ---------
    Notebook: MacBookPro | Late 2012, 16 GB RAM | Software: Mac OS X 10.8.2 | Parallels mit Ubuntu 12.4 mit XFCE und Windows 8 | NetAachen DSL 6000, FritzBox Fon 7270 | mehrere DD-WRT AP's

  11. #2
    Registrierter Benutzer Avatar von Ulli Ivens
    Registriert seit
    Jan 2001
    Ort
    Heinsberg im Rheinland, Deutschland
    Beiträge
    1.844

    Neue Version (1.2) dieser FAQ released !!

    gelöscht
    Geändert von Ulli Ivens (16.07.03 um 22:42 Uhr)
    Gruß Ulli

    ---------
    Notebook: MacBookPro | Late 2012, 16 GB RAM | Software: Mac OS X 10.8.2 | Parallels mit Ubuntu 12.4 mit XFCE und Windows 8 | NetAachen DSL 6000, FritzBox Fon 7270 | mehrere DD-WRT AP's

  12. #3
    Registrierter Benutzer Avatar von Ulli Ivens
    Registriert seit
    Jan 2001
    Ort
    Heinsberg im Rheinland, Deutschland
    Beiträge
    1.844

    Neue Version des Software HOWTOS online

    Ich habe eine neue Version fertig gestellt. Wichtig ist auch das sich die URL geändert hat. Ab sofort findet Ihr das HOWTO unter:

    http://howto.linux-hardware-shop.de/software.htm
    Gruß Ulli

    ---------
    Notebook: MacBookPro | Late 2012, 16 GB RAM | Software: Mac OS X 10.8.2 | Parallels mit Ubuntu 12.4 mit XFCE und Windows 8 | NetAachen DSL 6000, FritzBox Fon 7270 | mehrere DD-WRT AP's

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •