Klemens
Anmeldungsdatum: 29. Oktober 2010
Beiträge: 168
|
Entschuldigung - aber vielleicht wollen wir auch die konkrete Fragestellung von "hamster" ernst(er) nehmen. Mein bescheidener Beitrag: Vielleicht sucht der Compiler gar nicht unter /usr/include/gtk-3.0/gtk/gtk.h, sondern sonst wo. Meinem Gefühl! nach sollten ein paar Zeilen oberhalb da helfen können. Also ein bissi mehr an Zeilen darüber posten. Wenn ich mich richtig erinnere könnte auch der Inhalt von "Makefile" Hinweise geben. Da ich selber qt verwende und wenig Lust habe, mich näher in gtk*-dev hineinzuinstalliere/hineinzuarbeiten werde ich weiters keine große Hilfe sein ... Gute Nacht! Klemens P.S. - Wenn's nichts Geheimes ist, wäre es auch eine Hilfe, was Du da zu kompilieren versuchst.
|
glasenisback
Anmeldungsdatum: 20. November 2011
Beiträge: 1603
Wohnort: Fernwald (Gießen)
|
Sieht mir nach einem typischen C-Fehler aus. Auch wenn meine C-Kenntnisse nicht die Besten sind, weiß ich doch zwei Dinge: 1. C macht beim Einbinden von Header-Dateien einen Unterschied zwischen den Anführungszeichen und den Größer/Kleiner-Zeichen. Siehe auch den folgenden Link: http://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html#Include-Syntax Externe Header-Dateien müssen eigentlich immer per "#include <blablub.h>" eingebunden werden. 2. Falls das der Compiler trotz korrekter include-Anweisung die Header-Dateien nicht finden sollte, muss man diese per "-I"-Parameter an diesen übergeben: http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html#Search-Path Bei der Gtk+-Programmierung müsstest du als "-I"-Parameter den Pfad "/usr/include/gtk-3.0/gtk" übergeben, damit der Prä-Prozessor die Header-Datei "gtk.h" finden kann. Gerade bei Programmen, welche viele externe Header-Dateien benutzen, ist es fast zwingend notwendig sich mit der Erstellung eines "Makefile" zu beschäftigen. Dann muss man nicht immer die Compiler-Parameter von Hand schreiben. Erschöpfende Anleitungen lassen sich zuhauf per Google finden.
|
Klemens
Anmeldungsdatum: 29. Oktober 2010
Beiträge: 168
|
glasenisback, Ich fürchte mit Deinen Anweisungen sind so Leute wie hamster und ich überfordert. Wir machen sowas wie ./configure
make
make install und dann stehen wir mit großen Augen wie Kuh vor Kalb und denken daran: Wie schön war doch das Leben damals mit Bleistift und einem Blatt Papier. 😉 Gehört das Makefile editiert, oder wie geben wir dem Compiler bekannt, was er wo zu suchen hat? - Ist wohl auch der ursprünglichen Fragestellung nahe: "Warum klappt es nicht???, nie, und niemals, und verdammt noch mal darf es nicht auch einfach klappen???". Und wie kann ich als Laie auch einmal Erfolg haben, ohne den ganzen Krempel über 10 Semester durchzustudieren?? Ich muss editieren!:
Das soll keine Beleidigung sein und keinesfalls die gegebene Hilfestellung heruntermachen!!! DANKE!
|
dirkolus
Anmeldungsdatum: 17. Mai 2011
Beiträge: 2003
Wohnort: dahoam
|
glasenisback schrieb: Bei der Gtk+-Programmierung müsstest du als "-I"-Parameter den Pfad "/usr/include/gtk-3.0/gtk" übergeben, damit der Prä-Prozessor die Header-Datei "gtk.h" finden kann. Gerade bei Programmen, welche viele externe Header-Dateien benutzen, ist es fast zwingend notwendig sich mit der Erstellung eines "Makefile" zu beschäftigen. Dann muss man nicht immer die Compiler-Parameter von Hand schreiben. Erschöpfende Anleitungen lassen sich zuhauf per Google finden.
Genauso isses! Der -I Parameter wird allerdings erst bei make angegeben, und nachdem man das (autogenerierte) Makefile ja genausowenig anfassen will (sonst kann man gleich alles selbst programmieren), muss man an dieser Stelle beim 'configure' script bereits eine zusätzliche Option angeben, bspw.
./configure --prefix="/usr/qt-4.0/"
etwa, wenn die gesamte Entwicklungsumgebung (also Include-Files und Libraries) unter einem Directory ist, oder nur für Libraries
./configure --libs="/usr/lib/X11"
Entsprechendes gibt es auch für Deinen Fall, also für die Include-files, mir fällt die genaue Syntax leider gerade nicht ein, aber ein
./configure --help
sollte darüber Aufschluss geben. Dirk
|
k1l
Anmeldungsdatum: 22. September 2006
Beiträge: 1253
Wohnort: Köln
|
Klemens schrieb: Wir machen sowas wie ....
Da nimmt man aber besser checkinstall.
|
dirkolus
Anmeldungsdatum: 17. Mai 2011
Beiträge: 2003
Wohnort: dahoam
|
k1l schrieb: Da nimmt man aber besser checkinstall.
Nope: ./configure erstellt Deine Kompilierumgebung. make kompiliert die Software make install schiebt das fertig kompilierte Programm auf Deinem System in die entsprechenden Verzeichnisse
checkinstall erweitert nur den 'make install' Schritt, d.h. es baut ein Paket, was dann mit dpkg (oder rpm oder yum) bequem installiert werden kann. Um's kompilieren und um configure kommt man damit nicht drumrum. Dirk
|
k1l
Anmeldungsdatum: 22. September 2006
Beiträge: 1253
Wohnort: Köln
|
@ dirkolus Mir ging es um den Ersatz von make install. Gerade hinterher ist das Handling bessermit checkinstall. Siehe dein wikilink
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
Ja, interessant wäre schon, welches Paket versucht wird zu installieren, bzw wie der ./configure des TS aussieht, damit man bessere Hilfe geben kann 😉
|
MA_RI
Anmeldungsdatum: 9. Mai 2012
Beiträge: 217
|
dirkolus schrieb: k1l schrieb: Da nimmt man aber besser checkinstall.
Nope: ./configure erstellt Deine Kompilierumgebung. make kompiliert die Software make install schiebt das fertig kompilierte Programm auf Deinem System in die entsprechenden Verzeichnisse
checkinstall erweitert nur den 'make install' Schritt, d.h. es baut ein Paket, was dann mit dpkg (oder rpm oder yum) bequem installiert werden kann. Um's kompilieren und um configure kommt man damit nicht drumrum. Dirk
Checkinstall ist meist nur eine Krücke. Bau mal ffmpeg/libav mit checkinstall und nach Debian Art mit fakeroot debian/rules binary.
checkinstall liefert ein fertiges Paket, mit fakeroot debian/rules binary erhältst du acht oder neun.
Beide Varianten funktionieren, nur bei Variante "checkinstall" läuft der größte Teil am Paketmanagement vorbei. Ich behaupte mal das 95 Prozent aller Debian- und Derivate-Benutzer das Paketmanagement überhaupt nicht verstanden haben.
Nicht weil die Benutzer zu blöde sind, sondern weil es schlicht weg zu kompliziert ist und sehr schlecht dokumentiert.
Kann ja jeder mal probieren als Übung, MPlayer-Source zu "Debianisieren (dh_make)".
(Vorher 2 Liter Nerventonikum in der Apotheke kaufen) Beispielweise zu MPlayer gibt es haufenweise Anleitungen zum Kompilieren. Meist alle falsch.
Es gibt nur, mir bekannt, zwei richtige Anleitungen, im Debianforum-Wiki und hier im UU-Wiki.
|
glasenisback
Anmeldungsdatum: 20. November 2011
Beiträge: 1603
Wohnort: Fernwald (Gießen)
|
Nur so ein Tipp am Rande: Wer viel mit Eigenbaupaketen herumexperimentiert, sollte sich auf jeden Fall ein lokales Paket-Repository anlegen. Das geht sehr einfach. Alles was man tun muss, sind die folgenden Schritte zu befolgen: 1. Anlegen eines Verzeichnisses, welches die DEB-Dateien aufnehmen soll (Bei mir ist das "/home/debs". Ich habe meinem Hauptbenutzer alle Rechte an dem Verzeichnis zugewiesen, damit ich beim Aktualisieren der Pakete nicht immer "sudo" benutzen muss. 2. Anlegen einer Datei namens "local.list" mit dem folgenden Inhalt unter dem Verzeichnis "/etc/apt/sources.list.d":
3. Installation des Pakets "dpkg-dev" um an das Programm "dpkg-scanpackages" zu kommen. 4. Anlegen der Datei "/usr/local/bin/scan-debs" mit dem folgenden Inhalt:
| #!/bin/bash
pushd /home/debs > /dev/null
rm Packages.gz
dpkg-scanpackages ./ > Packages
gzip Packages
popd /dev/null
|
Die Datei muss dann per "sudo chmod +x /usr/local/bin/scan-debs" als ausführbar markiert werden. Um jetzt das lokale Repository in Betrieb zu nehmen, muss man jetzt folgendes tun: 1. Kopieren aller benötigten DEB-Pakete in das oben genannte Verzeichnis. 2. Aufruf des Skripts "scan-debs". Durch die Verwendung von "pushd" und "popd" spielt es keine Rolle von wo aus man es aufruft. 3. Aktualisieren des Paket-Caches per "apt-get update" 4. Danach kann man die Pakete ganz normal per Paketmanager installieren bzw. aktualisieren lassen. Man kann übrigens auch eine komplexe Verzeichnisstruktur unter "/home/debs" anlegen, um mehr Übersicht zu erhalten.
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10958
|
Hej Tim Petu, OT Tim Petu schrieb: [...]
'Ne 4 ist ausreichend. Wenn die Fehlermeldung aber ausreicht, wozu dann noch die Kommandozeile etc. *verwirrt* 😉
es war aber von 4- die Rede, und das ist imho man nur mal eben an fünf - setzen vorbeigeschrammt 😛 (wenn schon Zitat, dann bitte auch korrekt 😈 ) /OT Gruß black tencate
|
MA_RI
Anmeldungsdatum: 9. Mai 2012
Beiträge: 217
|
@glasenisback Kannst du nicht auf deinem Blog einen Artikel, oder gar Serie starten..Paketbau glas-klar, oder so...
|
olli1973
Anmeldungsdatum: 18. Januar 2009
Beiträge: 275
Wohnort: Velbert-Langenberg bei Essen
|
@glasen Danke für den Tip! 👍
|
VincentVale
Anmeldungsdatum: 11. Juni 2009
Beiträge: 317
Wohnort: Solingen
|
black tencate schrieb: Hej Tim Petu, OT Tim Petu schrieb: [...]
'Ne 4 ist ausreichend. Wenn die Fehlermeldung aber ausreicht, wozu dann noch die Kommandozeile etc. *verwirrt* 😉
es war aber von 4- die Rede, und das ist imho man nur mal eben an fünf - setzen vorbeigeschrammt 😛 (wenn schon Zitat, dann bitte auch korrekt 😈 ) /OT Gruß black tencate
4- ist immernoch bestanden. 😛
|
Trekker
Anmeldungsdatum: 14. März 2007
Beiträge: 334
|
Hallöchen! Es macht mir einen großen Spaß, Programme für mein Ubuntu zu kompilieren und somit auf dem neuesten Stand zu halten. Das ist beinahe wie mein täglich Brot. Anders würde ich es gar nicht mehr wollen. So bin ich heute halt. Es gibt kein Problem damit, höchstens im Einzelfall. Im Notfall könnte man sogar mit dem Entwickler sprechen. Nebenbei für seine Arbeit mal Danke sagen wäre auch cool. Nur mal so ein Gedanke.
Damals aber habe ich genauso gefühlt wie der Thread-Eröffnungstyp. Das war zu meinen SuSE-Zeiten, wo noch gar nix funktionierte. Das Größte, was man früher mal kompiliert hat, war der Kernel, um zum Bleistift mal ein paar Gamepads einzustreuen, aber auch nur deswegen, weil der Vorgang so gut im Buch dokumentiert wurde LOL
|