Code::Blocks 8.02 unter Linux installieren
-
Erhard Henkes schrieb:
Erzähl das lieber Leuten, die sich die Hose mit der Beißzange anziehen.
Wer unbedingt Metallhosen tragen möchte, muss sie sich eben mit der Beißzange anziehen.
Danke für den Link, sieht sehr einfach aus.
Das ist eine Anleitung für Entwickler, die unbedingt die aktuellste Nightly von Code::Blocks brauchen, sowas braucht nicht so furchtbar deppensicher zu sein. Unter Windows ist das auch nicht unbedingt wahnsinnig bequem: http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_nightly_build_on_Windows
Da nimmst Du dem Rechner sämtliche Deppenarbeit ab, auf die Du unter GNU/Linux verzichtest, was Dich eben ein paar Shellcommands kostet.
-
Ich hab da echt keinen Durchblick mehr:
Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut Reading state information... Fertig E: Konnte Paket build-essential nicht finden root@ehenkes-desktop:~# sudo apt-get install gdb Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut Reading state information... Fertig gdb ist schon die neueste Version. 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. root@ehenkes-desktop:~# sudo apt-get install libwxgtk2.8-0 Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut Reading state information... Fertig Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass Sie eine unmögliche Situation angefordert haben oder dass, wenn Sie die instabile Distribution verwenden, einige erforderliche Pakete noch nicht kreiert oder aus Incoming herausbewegt wurden. Da Sie nur eine einzige Operation angefordert haben ist es sehr wahrscheinlich, dass das Paket einfach nicht installierbar ist und eine Fehlermeldung über dieses Paket erfolgen sollte. Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen: Die folgenden Pakete haben nichterfüllte Abhängigkeiten: libwxgtk2.8-0: Hängt ab: libatk1.0-0 (>= 1.13.2) aber 1.12.3-0ubuntu1 soll ins talliert werden Hängt ab: libc6 (>= 2.6-1) aber 2.4-1ubuntu12 soll installiert werden Hängt ab: libfontconfig1 (>= 2.4.0) aber 2.3.2-7ubuntu2 soll in stalliert werden Hängt ab: libgcc1 (>= 1:4.2.1) aber 1:4.1.1-13ubuntu5 soll inst alliert werden Hängt ab: libglib2.0-0 (>= 2.14.0) aber 2.12.4-0ubuntu1 soll in stalliert werden Hängt ab: libgstreamer-plugins-base0.10-0 (>= 0.10.14) aber 0.1 0.10-1ubuntu1 soll installiert werden Hängt ab: libgstreamer0.10-0 (>= 0.10.14) aber 0.10.10-1ubuntu2 soll installiert werden Hängt ab: libgtk2.0-0 (>= 2.12.0) aber 2.10.6-0ubuntu1 soll ins talliert werden Hängt ab: liborbit2 (>= 1:2.14.8) aber 1:2.14.3-0ubuntu2 soll i nstalliert werden Hängt ab: libpango1.0-0 (>= 1.18.3) aber 1.14.5-0ubuntu1 soll i nstalliert werden Hängt ab: libpng12-0 (>= 1.2.13-4) aber 1.2.8rel-5.1 soll insta lliert werden Hängt ab: libstdc++6 (>= 4.2.1) aber 4.1.1-13ubuntu5 soll insta lliert werden Hängt ab: libwxbase2.8-0 (>= 2.8.8.0) soll aber nicht installie rt werden Hängt ab: libxcomposite1 (>= 1:0.3-1) aber 1:0.3-0ubuntu1 soll installiert werden Hängt ab: libxdamage1 (>= 1:1.1) aber 1:1.0.3-0ubuntu1 soll ins talliert werden Hängt ab: libxml2 (>= 2.6.29) aber 2.6.26.dfsg-2ubuntu4 soll in stalliert werden Hängt ab: libxrandr2 (>= 2:1.2.0) aber 2:1.1.1-0ubuntu1 soll in stalliert werden Hängt ab: zlib1g (>= 1:1.2.3.3.dfsg-1) aber 1:1.2.3-13ubuntu2 s oll installiert werden E: Kaputte Pakete
Ich weiß noch nicht mal, welche Version Kubuntu ich installiert habe, wo kann man das nachschauen? KDE 3.5.5, mehr finde ich nicht.
-
Eigentlich bist Du doch schon lange genug hier, um Code-Tags zu verwenden, oder?
Erhard Henkes schrieb:
Hier meine sources list:
deb http://apt.wxwidgets.org/ gutsy-wx main
Alles sonst deutet stark daraufhin, dass Du edgy verwendest, warum behauptest Du hier, gutsy zu verwenden? Ersetze das "gutsy-wx" mal durch "edgy-wx" und probier dann nochmal.
-
Ja, das hat geklappt mit wx..., aber die Code::Blocks Installation lief dennoch nicht ab. Edgy - Gutsy - Hardy Heron ??? Nun, ist gut.
Ich habe gerade die Platte mit Partition Magic geputzt.
Ich werde es nochmals mit Kubuntu 8.04 probieren. Auf jeden Fall wieder etwas gelernt: Linux sollte man vermutlich immer als root aus der Konsole bedienen analog dem guten alten DOS. Linux ist vermutlich eine "echte Alternative" zu Bunti-Klicki.
-
Erhard Henkes schrieb:
Auf jeden Fall wieder etwas gelernt: Linux sollte man vermutlich immer als root aus der Konsole bedienen analog dem guten alten DOS. Linux ist vermutlich eine "echte Alternative" zu Bunti-Klicki.
Ist es tatsächlich
Jedoch root nur zum installieren/konfigurieren!
-
Erhard: Wenn man Doku nicht vernünftig liest, unvollständige Posts ohne Fehlermeldungen absetzt und dann aus lauter Ungeduld einfach _irgendwas_ macht, wird man wohl auch als root auf der Konsole nicht sehr glücklich werden.
Dürfte aber wohl ohnehin für die meisten Betriebssysteme gelten - auch für Dein "gutes" altes DOS (optional mit Fenstern).
-
wie wärs mit mac, habe grad gehört, da kann man nix falsch machen *duck*
-
Selbst mit Kubuntu 8.04 - genannt "Hardy" - ist es mir nicht gelungen, Code::Blocks zu installieren. Die wx... 2.8.0 libs konnte man in Adept leicht installieren. Dies war diesmal nicht das Problem, sondern die Installation der sieben deb-Pakete. Diese passen irgendwie nicht zu sich selbst, einfach lächerlich.
Aber wieder habe ich etwas gelernt. Solche Befehle wie "apt-get update" oder "sudo apt-get install -f" gehen mir bereits flüssig von der Hand. Allerdings war ich etwas säuerlich, als ich alle sieben Namen der Pakete in die Konsole ("sudo dpkg -i dateiname_1.deb ... dateiname_7.deb") kopiert hatte, weil im Internet jemand behauptet hatte, das würde über die "Unverträglichkeiten" hinweg helfen, was es sogar tat (Console rulez), aber anschließend musste apt-get das wieder "abräumen" (contrib ...) wegen Blödsinn. Auf jeden Fall ist Code::Blocks nicht ein einziges mal gelaufen. Die Installation war bei "Edgy" easy, lief fast von alleine (hab nur leicht mit der Maus berührt).
Nachdem ich nun also doch schon einige "Befehle" beherrsche, werde ich als alter DOS-Geplagter nicht mehr aufgeben (auch wenn dir jetzt ls heisst). Ich möchte nun den vollen Linux-Schmerz.
Also, im Ernst, wie kommt man in solchen Fällen allgemein weiter?
Zur Zeit habe ich Kubuntu 8.04.1 - genannt Hardy - und wollte Code::Blocks 8.02 für 32-bit-Linux aufspielen.Gibt es eine ideale Seite, auf der die wichtigsten Linux-Befehle aufgeführt sind? (habe nur ein altes Buch über SuSE Linux 8.x)
-
Erhard Henkes schrieb:
Gibt es eine ideale Seite, auf der die wichtigsten Linux-Befehle aufgeführt sind?
Was ist denn eine "ideale Seite"?
Man könnte z.B. direkt beim Hersteller für einen ersten Überblick nachschlagen:
http://www.gnu.org/software/coreutils/manual/coreutils.html
(oder lokal: info coreutils)Wenn ich schon weiß, welches Programm ich brauche, dann lese ich noch
'man programmname',
damit ich die genauen Parameter kenne.
-
Erhard Henkes schrieb:
Diese passen irgendwie nicht zu sich selbst, einfach lächerlich.
Das wäre natürlich nicht Ubuntus Schuld, sondern dann liegt das Problem bei Code::Blocks. Aber egal, denn eigentlich sollte es dir ja egal sein können, wer genau es verbockt hat.
weil im Internet jemand behauptet hatte, das würde über die "Unverträglichkeiten" hinweg helfen, was es sogar tat (Console rulez), aber anschließend musste apt-get das wieder "abräumen" (contrib ...) wegen Blödsinn.
Was hat apt-get denn genau gesagt?
Ich möchte nun den vollen Linux-Schmerz.
Wie wäre es denn dann, wenn du Code::Blocks einfach selbst kompilierst?
Und nein, das ist jetzt nicht wirklich als Witz gemeint. Das Paketmanagement von Ubuntu ist klasse, aber eben nur solange man Pakete direkt von Ubuntu installiert, oder welche die genau auf die jeweilige Distribution zugeschnitten sind. Mit unpassenden (oder einfach nur schlecht gemachten) Paketen hat man, wie du ja schon gesehen hast, nicht viel Spaß. Und da gibt's dann meistens auch keine schönen und einfachen Lösungen, um die Abhängigkeiten wieder geradezubiegen.
Also, Quellcode von Code::Blocks runterladen, von allen benötigten Libraries die entsprechenden -dev Pakete installieren, und dann "./configure && make && sudo make install"... Viel Erfolg
-
Um eine 3D-Graka zum Laufen zu bekommen, musste ich den Linux Kernel neu kompilieren (musste damals etwa 50 Zeilen aus dem Internet abtippen, die ich nicht verstand, hat aber geklappt). Das ist schon einige Zeit her. Ich dachte, das wäre nun vorbei. Auf die Idee, 3D-Anwendungen damit durchzuführen, komme ich erst garnicht, wenn noch nicht mal eine einfache IDE funktioniert.
Nicht installieren, sondern compilieren? Mir wird wahrscheinlich bei Code::Blocks nichts anderes übrig bleiben, wenn ich keine Anweisung im Net finde. Meine Meinung dazu möchte ich besser nicht verewigen.
So langsam finde ich MS Windows richtig "usable".
-
Nun habe ich es nochmals probiert und die sieben Pakete einzeln installiert. Das hat funktioniert. Auf so etwas muss man als Linux-Einsteiger erst mal kommen. Logischerweise wählt man doch einfach alles aus, was man installieren möchte, um nicht durcheinander zu kommen. Wie auch immer, Code::Blocks 8.02 läuft auf "hardy".
Um etwas Positives über diese Linux-Distribution Kubuntu 8.04 zu sagen:
- Konqueror hatte ohne weitere Einstellungen sofort Verbindung zum Internet.
- OpenOffice ist komplett dabei
- F5, Strg+C, Strg+V sind identisch zu MS Windows
-
Was ist am compilieren so schlimm? für die meisten anwender ist es nicht mehr als ein ./configure && make && make install. Das ist sogar trivialer als die meisten windows installer. Linux ist nicht Windows, und vorallem es ist kein homogenes system. Was man bei windows mitgeliefert bekommt, kann man sich unter linux mit 100 verschiedenen programmkombinationen individuell zusammenstellen. natürlich hat das auch einen Effekt auf die geschriebenen Programme. wxwidgets zum Beispiel kommt mit Backends zu 5 verschiedenen zeichen bibliotheken daher. Deshalb wurden so tolle Dinger wie configure scripts entwickelt, die sich individuell darum kümmern, dass die beste kombination genommen wird, und das alles gut zusammen funktioniert.
Packages waren ein Gedanke, das zu vereinfachen, aber das kann nicht funktionieren. In einer Distribution muss alles zusammen funktionieren können, was zur folge hat, dass diejenigen die sich um die pakete kümmern darum sorge tragen müssen, dass ein update den restlichen paketen nicht schadet. je mehr pakete es werden, desto schwieriger wird das aber, vorallem bei libs wie wxwidgets die sich in permanenter Entwicklung befinden und sich darum ihr interface zwischen den einzelnen Versionen unterscheidet.
Dies verlangsamt den Prozess der Paketverwaltung, sodass es dann sehr schnell dazu kommt, dass externe packages für die plattform auf bibliotheken basieren, die in der Destribution selbst noch lange nicht stable sind und inkompatibilitäten zu anderen packages aufweisen. Wie in diesem Fall Code::Blocks dass einfach eine relativ neue wxwidgets und glibc version braucht(Anmerkung am Rande: Debian stable hat _immernoch_ nicht glibc2.7 im stable repository).
-
Frage 1: Wenn man (z.B. für Veröffentlichungen im Internet) ein HTML-Dokument schreiben will, welches Werkzeug empfiehlt sich diesbezüglich?
Frage 2: Wie erzeugt man Bildschirm- bzw. Teilbildschirm Snapshots?
Frage 3: Was ist das Pendant zu MS "Paint"?
Frage 4: Was benützt man zur FTP-Übertragung auf die eigene Homepage?
-
Erhard Henkes schrieb:
Frage 1: Wenn man (z.B. für Veröffentlichungen im Internet) ein HTML-Dokument schreiben will, welches Werkzeug empfiehlt sich diesbezüglich?
dein bevorzugter Texteditor?
Frage 2: Wie erzeugt man Bildschirm- bzw. Teilbildschirm Snapshots?
kde? -> ksnapshot
Frage 3: Was ist das Pendant zu MS "Paint"?
gimp
Frage 4: Was benützt man zur FTP-Übertragung auf die eigene Homepage?
Das kommandozeilenprogramm ftp. Ist bei fast jedem linux standardmäßig dabei. Sagt zumindest google.
//edit der ftp link wird durch die forensoftwäre erzeugt
//test: ftp
-
Was ist am compilieren so schlimm?
Alles, was auf Anhieb klappt, ist "nicht schlimm". Es geht daher immer um die Fehlermöglichkeiten, und davon gibt es beim Compilieren sicher genug.
Ein Anwender, der ein neues "Programm" (wieviele Pakete oder Dateien da drinnen sind, ist dem Normalanwender i.d.R. egal) aufspielen will, sucht genau einen Startknopf zum Installieren.Aber ich werde dies schon noch verstehen lernen. Vielleicht erkenne ich irgendwann auch einmal die Attraktivität von Linux. Auf jeden Fall ist bisher alles "kostenlos". Das ist ein gewichtiges Argument gegenüber MS Windows.
@otze: Danke für die Tipps! Bevorzugter Texteditor? Habe noch keinen bei Kubuntu. Wichtig ist, dass HTML-Dateien erzeugt werden, die auf allen Browsern ordentlich aussehen. Unter MS Windows verwende ich z.Z. den Composer aus SeaMonkey.
-
SeaMonkey läuft auch unter GNU/Linux.
Und das Pendant zu MSPaint ist eigentlich eher TuxPaint.
-
Erhard Henkes schrieb:
Alles, was auf Anhieb klappt, ist "nicht schlimm". Es geht daher immer um die Fehlermöglichkeiten, und davon gibt es beim Compilieren sicher genug.
Natürlich gibt es viele Sachen, die dabei schiefgehen können (der typische Anfängerfehler wäre, zwar z.B. das Paket libfoo installiert zu haben, nicht aber libfoo-dev).
In den meisten Fällen geht das Kompilieren aber ziemlich reibungslos. Der Großteil der Linux-Software ist von vornherein darauf ausgelegt, im Sourcecode ausgeliefert und vom Benutzer selbst kompiliert zu werden. Wenn du bisher nur unter Windows entwickelt hast wirst du überrascht sein, wie unkompliziert sowas sein kann...
-
Danke für die Tipps!
Musste mir noch den C++-Compiler/Linker einrichten, da habe ich g++ 4.2 gewählt, hat auch alles bestens geklappt.
-
Ein Link, der den Einstieg in Linux kompakt und strukturiert unterstützt, wenn man DOS kennt: http://www.linuxhaven.de/dlhp/HOWTO/DE-DOS-nach-Linux-HOWTO.html#toc3
Das Schlimme an KDE ist, dass es aussieht wie Windows, aber ohne die Konsole und ohne Kenntnis der speziellen Kommandos geht nichts auf Dauer.
Das ich mein Programm nach dem Erstellen mit ./myprogram ausführen musste, war mir nicht einleuchtend.
Was mir gefällt, ist die hohe Qualität der mitgelieferten bzw. einfach installierbaren Tools, z.B. Gimp Image Editor oder KSnapshot.