• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Probleme beim Compilieren - athlon64?

Hallo erstmal alle zusammen,
bin neu hier und wollte mich mal kurz vorstellen :)
Also ich arbeite schon recht lange mit suse (seit version 4.4) und will nun mein system komplett auf linux bzw. suse umstellen.

Nun zu meinem Problem.
Wenn ich versuche ein Programm zu compilieren, erhalte ich immer "Variablenfehler". z.b.:
snow.c:3248: warning: assignment from incompatible pointer type
oder auch
snow.c:3736: warning: format '%Ld' expects type 'long long int', but argument 4 has type 'uint64_t'

<-- Die Programme lassen sich (bis auf sehr wenige Ausnahmen) nicht compilieren

ich denke, dass das problem mit meiner cpu (athlon64) zusammenhängt. Das configure Script gibt mir folgendes aus :
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu

bei nem kumpel wird hier als type wohl athlon64 erkannt. warum nicht bei mir?
auch uname gibt nur x86_64 aus.

auch ein ./configure mit libsuffix=64 hat keine Besserung ergeben oder auch ein export der CCFLAG mit -mtune=athlon64 und -march=athlon64 war nicht erfolgreich :(


Meinen Kernel habe ich frisch gebaut,mit aktivierter Athlon64 Option.
Hat vielleicht jemand eine Idee? Wäre euch sehr verbunden

Vielen Dank im Vorraus

Gruß
der Schrat

p.s.:
BS: Suse 10.0 x84_64
CPU: Athlon 64 3000+
Motherboard: Asus A8V-E deluxe
 
Du solltest dringendst zwischen Hinweisen des Compilers und Fehlern unterscheiden. Eiserne Regel: Wenn in einer Ausgabe des Compilers das Wort "warning" drin steht, dann ist es kein Fehler (engl. "warning" = dt. "Hinweis").

Was die Fehler beim Kompilieren angeht: Du hast leider keinen einzigen genannt (die genannten Beispiele sind ja, wie gerade klargestellt, keine Fehler), deswegen kann Dir so leider keiner helfen. Also such doch bitte nochmal ein Programm aus, das sich nicht kompilieren lässt, und poste dann ganz konkret auf dieses Programm bezogen den wirklichen Fehler (also die Zeilen, in denen nicht "warning", sondern "error" steht).
 
Hmm joa stimmt eigentlich, warning ist ja nicht gleich Fehler... :D
Aber sind diese warnings denn nicht "schlecht"? oder beeinflussen die den späteren ablauf nicht?
Naja wenns da net dran liegt dann sollte ich vll mal das system frisch installieren, evtl. ist ja auch was bei der installation schiefgegangen.

Trotzdem noch vielen dank für die prompte antwort :wink:

gruß
der Schrat
 
der_Schrat schrieb:
Aber sind diese warnings denn nicht "schlecht"?
Doch, schlecht sind sie auf jeden Fall, aber diese eine, die Du genannt hast, hat genau gar nichts mit Kompilier-Fehlern zu tun. Nenn doch einfach den Fehler, der ganz am Ende kommt, anstatt dass wir hier allgemein philosophieren.
der_Schrat schrieb:
oder beeinflussen die den späteren ablauf nicht?
Es ist unmöglich, das ohne Originaltexte einzuordnen.

Wenn Du an der Stelle Hilfe brauchst, dann nenne die Originaltexte: Im Terminal markieren, kopieren und dann hier einfügen. Anders geht es nicht. Niemand kann die Warnungen und Fehlermeldungen erraten!

Und "frisch installieren" ist vermutlich Quatsch, besser wäre es, wenn Du die Originaltexte abliefern würdest, aber nochmal werde ich nicht danach fragen.

PS: --enable-libsuffix=64 ist KDE-spezifischer Kram, ob das was bringt, kann keiner wissen, weil Du ja nicht mal sagst, welches Programm Du kompilieren willst. Bei "normalen" autotools-Projekten wird --enable-libsuffix=64 weder gebraucht noch hat es überhaupt irgendeinen Effekt.
 
Diese warnings habe ich jetzt nicht speziell auf ein programm bezogen, sondern darauf dass diese fast immer auftreten. fehler sinds dann doch eher selten, aber warnings sind eigentlich immer dabei.

--> Deshalb dachte ich, dass das vll mit der cpu zusammenhängt, weil mir auf meinem alten 32bit system eigentlich nie solche warnings aufgelfallen sind.

Nenn doch einfach den Fehler, der ganz am Ende kommt, anstatt dass wir hier allgemein philosophieren

beim compilieren von qtguitunetritt z.b folgender fehler auf:
localhost:/home/chris/Desktop/qtguitune-0.5 # ./configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... missing
checking for mawk... no
checking for gawk... gawk
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for c++... c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for main in -libs... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for fcntl.h... yes
checking for sys/ioctl.h... yes
checking for unistd.h... yes
checking for working const... yes
checking whether gcc needs -traditional... no
updating cache ./config.cache
creating ./config.status
creating Makefile
und jetzt zur eigentlichen fehlermeldung :D
localhost:/home/chris/Desktop/qtguitune-0.5 # make
c++ -DPACKAGE=\"qtguitune\" -DVERSION=\"0.5\" -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_UNISTD_H=1 -I. -I. -I/usr/lib/qt3/include -g -O2 -c main.cpp
c++ -DPACKAGE=\"qtguitune\" -DVERSION=\"0.5\" -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_UNISTD_H=1 -I. -I. -I/usr/lib/qt3/include -g -O2 -c guitune.cpp
c++ -DPACKAGE=\"qtguitune\" -DVERSION=\"0.5\" -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_UNISTD_H=1 -I. -I. -I/usr/lib/qt3/include -g -O2 -c logview.cpp
logview.cpp: In constructor ‘LogView::LogView(QWidget*, char*, uint, bool)’:
logview.cpp:50: error: no matching function for call to ‘QFrame::QFrame(QWidget*&, char*&, uint&, bool&)’
/usr/lib/qt3/include/qframe.h:132: note: candidates are: QFrame::QFrame(const QFrame&)
/usr/lib/qt3/include/qframe.h:61: note: QFrame::QFrame(QWidget*, const char*, uint)
make: *** [logview.o] Fehler 1
localhost:/home/chris/Desktop/qtguitune-0.5 #

Die Qt Pakete sind so ziemlich alle installiert.

PS: --enable-libsuffix=64 ist KDE-spezifischer Kram, ob das was bringt, kann keiner wissen, weil Du ja nicht mal sagst, welches Programm Du kompilieren willst. Bei "normalen" autotools-Projekten wird --enable-libsuffix=64 weder gebraucht noch hat es überhaupt irgendeinen Effekt.

Beim (vergeblichen) Versuch amaroK unter Slamd64 zu installieren habe ich beim recherchieren einen forumbeitrag gefeunden, in dem darauf hingewiesen wurde diese option zu benutzen, da wohl das configure-skript u.U. die 64bit-libs nicht findet.
aber die option hats wohl net so gebracht :)

naja dann werde ich mal versuchen mich da noch n bissl einzuarbeiten. :)
aber trotzdem vielen dank für eure hilfe
 
error: no matching function for call to ‘QFrame::QFrame(QWidget*&, char*&, uint&, bool&)’
Dieser Quellcode scheint uralt zu sein und ist nicht kompatibel mit einer aktuellen Qt-Version. Aktuell ist Qt4.x, momentan baut KDE auf Qt3.x auf. Bei keiner dieser Versionen gibt es QFrame::QFrame mit 4 Argumenten. In der Trolltech-Dokumentation ist nur bei Qt2.3 so etwas zu finden.
 
Jup die letzte qtguitune Version ist von 2001.
Versuch lieber mal die KDE-Version:

http://home.planet.nl/~lamer024/k3guitune.html

MfG
 
Oben