4. kdevelop funktioniert nicht

kdevelop funktioniert nicht

  • ?

    Hallo!

    Ich wolle unter Linux die Entwicklungsumgebung "kdevelop" installieren, die ich vom Internet runtergeladen habe. Außerdem habe ich die Mesa-Bibliothek runtergeladen, da ich später auch mal OpenGL-Anwendungen schreiben will.
    Aber egal was ich mache: Nichts funktioniert: Wenn ich die Beispiele aus dem Mesa-Paket kompilieren will bekomme ich massenhaft Fehlermeldungen "undefined reference to 'glClearColor'" und so ähnliche. Ich habe viele Beispiele ausprobiert, die ich von verschiedenen Websites runtergeladen habe. Es kann doch nicht sein dass die alle nicht funktionieren. Was habe ich falsch gemacht?

    Bei kdevelop habe ich auch ein Problem: Das rpm-Paket lässt sich nicht installieren, da Abhängigkeiten (cvs, kdesdk3, usw.) nicht gefunden werden. Natürliche finde ich diese Pakete auch nicht auf meinen CDs (SusE 8.0).

    Kann mir bitte jemand genau sagen was ich installieren muss (und woher ich die Pakete bekomme), damit dieses kdevelop funktioniert und damit ich auch OpenGL verwenden kann?

    Danke im Voraus!

    mfg

    0
  • M

    Wieso hast du den KDevelop aus dem Internet geladen? Ist das Paket denn bei deiner SuSE-Distri nicht dabei?
    Wenn du bei SuSE mit YAST Pakete installierst, kann man die fehlenden Pakete doch automatisch mitinstallieren lassen, sodass die Abhängigkeiten erfüllt sind.

    Im Übrigen: Meiner persönlichen Meinung nach ist KDevelop für Einsteiger (so hast du dich ja bezeichnet) nicht unbedingt zu empfehlen. Ich würde erst einmal ohne das ganze "Drumherum" einer komplexen Entwicklungsumgebung starten. Mit "nedit", "gcc", "make" und "DDD" kann man auch so ganz vernünftig arbeiten. (Jetzt werde ich bestimmt von einigen Linux-Programmierern gesteinigt, aber ich komme halt aus der UNIX-Welt und arbeite am liebsten in der Shell.) Mehr dazu steht in meinem Buch "C und Linux" 😃

    Noch ein Tipp: Schau' dir doch mal "Anjuta" an! Diese IDE finde ich etwas übersichtlicher als KDevelop.

    0
  • C

    @ Martin:
    Da stimme ich ich dir zu. Ich arbeite auch fast ausschließlich mit gcc + co und muss sagen, dass man damit wirklich gut arbeiten kann. Wenn man den Vi beherrscht, kann man schon ganz dolle Dinge damit machen :D. Allerdings muss ich auch gestehen, dass ich so richtig große Projekte noch nicht gemacht habe.

    Wie auch immer, ich fürchte ja, dass die Probleme mit Anjuta auch nicht abnehmen. Ich installiere das nämlich auch gerade, und muss allerhand aktuellen Pakete dafür einspielen :(.

    0
  • R

    Kommt drauf an, aus welcher ecke man kommt ...

    Sicher hab ich mich auch mit kompilerflags beschaeftigt ...
    SIcher hab ich nen c++ program in nem einfachen editor (war in dem fall der vom mc) geschrieben und uebersetzt ...
    Hab auch ne Weile gebraucht um das hinzubekommen ...

    Aber fuer nen Umsteiger, der von der Windowswelt kommt, und unter Linux seine ersten Programme mit der STL und simplen Consolen-Ein und Ausgaben testen will, wuerde ich diese vorgehensweisse nicht empfehlen, weil der frustfaktor einfach viel zu hoch ist. 10 min nen simples programm schreiben, und dann 2 Tage Dokus lesen und an Compilerflags rumschrauben, bis es denn endlich uebersetzt und irgendwann auch mal ausgefuehrt wird .. steht eigentlich in keinem verhaeltniss. Da finde ich ne Konsolenapp unter KDevelop zu erstellen gerechtfertigt.

    Wenn wer die Mesa Lib, QT oder ähnliches einbinden will, dann habt ihr recht, sollte er sich schon erst mal mit dem konzept der Bibliotheken und Unix allgemein auseinandersetzen ... wird ja auch ned drumherumkommen.

    Und wer richtig tief und boese in Linux rumprogrammieren will, der wird eh Linux Dokus auswendig lernen muessen, oder zumindest die immer ausgedruckt neben sich liegen haben ...

    Ciao ...

    0
  • M

    RHBaum schrieb:

    ... und dann 2 Tage Dokus lesen und an Compilerflags rumschrauben, bis es denn endlich uebersetzt und irgendwann auch mal ausgefuehrt wird

    Wieso Dokus und Compilerflags? Für die ersten Programme (ohne grafische Oberfläche o. ä.) reicht

    gcc Quelltext -o Binary

    doch aus. Bei Aufteilung auf mehrere Quelltexte kommt noch die Option "-c" hinzu (und ggf. noch "-l" für 'ne Lib), das war's dann auch schon.

    Martin

    0
  • ?

    Hallo!

    Was machen die Compiler-Flags -I und -L eigentlich genau? Ich nehme an I bedeutet wo der Compiler noch nach Include-Dateien suchen soll (außer im Standardverzeichnis), aber was bedeutet -L?

    Andere Frage: Include-Dateien werden ja direkt in die Binärdatei eingebunden, müssen also auf dem Zielrechner nicht vorhanden sein, wie schaut es mit Dateien aus, die erst beim Linken hinzugefügt werden?

    mfg

    0
  • M

    Einsteiger schrieb:

    Andere Frage: Include-Dateien werden ja direkt in die Binärdatei eingebunden, müssen also auf dem Zielrechner nicht vorhanden sein, wie schaut es mit Dateien aus, die erst beim Linken hinzugefügt werden?

    Include-Dateien werden gar nicht "eingebunden". Die Include- oder auch Header-Dateien enthalten - wenn man's richtig macht - keinen Code sondern nur Deklarationen, damit der Compiler z.B. weiß, von welchem Typ der Rückgabewert einer Funktion ist und welche Parameter die Funktion erwartet (der Linker überprüft das nämlich nicht).

    Die Option "-L" gibt zusätzliche Pfade an, in denen nach Funktions-Bibliotheken (Libraries) gesucht werden soll.

    Versuch's doch mal mit "man gcc". Da steht alles drin.

    Martin

    0
Anmelden zum Antworten