Hallo, auf meinem - mittlerweile wohl völlig verkorksten *g* - System habe ich in letzter Zeit ein paar Updates eingespielt, und eigentlich läuft auch alles so, wie es soll. Das System ist ein ehemaliges SuSE 6.3 mit selbst kompilierten vanilla 2.4.3-Kernel, reiserfs, den aktuellen Security-Updates für die 6.4 von SuSE (unter anderem libc.so.6 in der Version GLIBC_2.1.2) und dem gcc 2.95.2 von der 7.1 (?) als rpm installiert. Wie gesagt, prinzipiell läuft es. Jetzt möchte ich auf 2.4.18 updaten und brauche dafür den gcc 2.95.3. Ich habe das SRPM von der 7.2 installiert und versuche, das RPM neu zu bauen. Dabei kommen folgende - für mich leider nicht verständliche - Meldungen: ... ln -s ../../gcc/../libiberty/splay-tree.c splay-tree.c gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include splay-tree.c gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include ../../gcc/graph.c gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include ../../gcc/sbitmap.c gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include ../../gcc/resource.c gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include ../../gcc/hash.c gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include -c ../../gcc/c-parse.c /usr/share/bison.simple:172: conflicting types for `yyparse' ../../gcc/tree.h:2083: previous declaration of `yyparse' make[2]: *** [c-parse.o] Error 1 make[2]: Leaving directory `/mnt/hdg1/src/packages/BUILD/gcc-2.95.3/obj-i486-suse-linux/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/mnt/hdg1/src/packages/BUILD/gcc-2.95.3/obj-i486-suse-linux/gcc' make: *** [bootstrap] Error 2 Bad exit status from /var/tmp/rpm-tmp.79929 (%build) Kann mir da mal jemand einen Tip geben, in welche Richtung ich suchen soll? Oder ob ich gleich aufgeben soll? *g* Gruß, Sebastian -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome)
Hallo Sebastian, hast Du flex, Serie d (glaube ich) installiert? Per Hand? Sind vielleicht mehrere Versionen installiert, hast Du ldconfig ausprobiert? Gruß Sebastian www.wolfgarten.com
Moin Sebastian, ich lese die Liste, bitte kein cc ;-) * Sebastian Wolfgarten schrieb am 29 Jul 2002:
hast Du flex, Serie d (glaube ich) installiert?
helms@narya:~ (0) > flex --version flex version 2.5.4
Per Hand?
helms@narya:~ (0) > rpm -qf /usr/bin/flex flex-2.5.4-107 Nein, ist original.
Sind vielleicht mehrere Versionen installiert
von flex? Wüßte nicht, woher.
hast Du ldconfig ausprobiert?
Wozu, wie? Gruß, Sebastian -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome)
Hallo Sebastian, lass mal ein "ldconfig" laufen, eventuell bringt das was (glaube ich aber nicht). Hast Du einen Teil der Fehlermeldung mal bei google reingehauen? Welche glibc Version braucht der gcc 2.95? gruß sebastian
* Sebastian Wolfgarten schrieb am 29.Jul.2002:
hast Du flex, Serie d (glaube ich) installiert? Per Hand? Sind vielleicht mehrere Versionen installiert, hast Du ldconfig ausprobiert?
Ne, ne. Bison hat einen Conflikt entdeckt und seine Arbeit aufgegeben. Bison bearbeitet Dateien, die die Syntax einer Sprache festlegt, und macht daraus ein C-Programm, das ein Compiler für diese Sprache ist. Manche Konflikte lassen sich auflösen, andere nicht. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Sebastian Helms
Jetzt möchte ich auf 2.4.18 updaten und brauche dafür den gcc 2.95.3.
Versuche es doch mal mit den Paketen für die 7.1, welche du unter ftp://ftp.gwdg.de/pub/linux/suse/people/pthomas/gcc/7.1 findest. Die sollten eigentlich auch unter 7.2 tun.
Ich habe das SRPM von der 7.2 installiert und versuche, das RPM neu zu bauen. Dabei kommen folgende - für mich leider nicht verständliche - Meldungen:
-I../../gcc/config -I../../gcc/../include -c ../../gcc/c-parse.c /usr/share/bison.simple:172: conflicting types for `yyparse' ../../gcc/tree.h:2083: previous declaration of `yyparse'
Da passt was ganz und gar nicht. Ich vermute mal, das es eines der Bison-Probleme ist, sprich das nicht alle blablub.y mit *derselben* Version von Bison verarbeitet wurden. Philipp -- Philipp Thomas work: pthomas@suse.de Entwicklung, SuSE Linux AG private: philippt@t-online.de
* Philipp Thomas schrieb am 30.Jul.2002:
Da passt was ganz und gar nicht. Ich vermute mal, das es eines der Bison-Probleme ist, sprich das nicht alle blablub.y mit *derselben* Version von Bison verarbeitet wurden.
Wie? make benutzt verschiedene bison? Oder was? blablub.y wurde mit einem Editor erstellt, da war noch kein bison dran. bison macht aus einem blablub.y ein blablub.c, woraus ein C-Compiler dann ein blablub machen kann. Es könnte natürlich sein, daß blablub.y einen bison mit höherer Versionsnummer benötigt, als Sebastian hat. Allerdings gibt es yacc, den Vorläufer von bison, schon so lange, daß man doch bestimmt ohne solche Sachen auskommen müßte. Ist wie bei bash-skripte, da sollte man tunlichst auch nur Standard Bourne-Shell Sachen verwenden, vor allem, wenn man es weitergibt. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9
B.Brodesser@t-online.de [30 Jul 2002 07:58:59 +0200]:
Wie? make benutzt verschiedene bison? Oder was? blablub.y wurde mit einem Editor erstellt, da war noch kein bison dran. bison macht aus einem blablub.y ein blablub.c, woraus ein C-Compiler dann ein blablub machen kann.
Nein, was ich meinte waren abweichende timestamps. Im tarball liegen normalerweise neben den .y Dateien auch die mittels Bison generierten entsprechenden .c Dateien bei. Wenn jetzt nicht entweder alle entsprechenden .c Dateien getouched werden oder aber nicht *alle* .y Dateien neu durch Bison gejagt werden, hast du .c Dateien, die u.U. mit verschiedenen Versionen von Bison generiert wurden. Philipp -- Philipp Thomas work: pthomas@suse.de Entwicklung, SuSE Linux AG private: philippt@t-online.de
Moin Philipp, * Philipp Thomas schrieb am 31 Jul 2002:
B.Brodesser@t-online.de [30 Jul 2002 07:58:59 +0200]:
Wie? make benutzt verschiedene bison? Oder was? blablub.y wurde mit einem Editor erstellt, da war noch kein bison dran. bison macht aus einem blablub.y ein blablub.c, woraus ein C-Compiler dann ein blablub machen kann.
Nein, was ich meinte waren abweichende timestamps. Im tarball liegen normalerweise neben den .y Dateien auch die mittels Bison generierten entsprechenden .c Dateien bei. Wenn jetzt nicht entweder alle entsprechenden .c Dateien getouched werden oder aber nicht *alle* .y Dateien neu durch Bison gejagt werden, hast du .c Dateien, die u.U. mit verschiedenen Versionen von Bison generiert wurden.
Hm.. aber das erklärt nicht den Fehler innerhalb einer .yy Datei, oder versteh ich dich falsch? Gruß, Sebastian -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.sh/faq/
* Sebastian Helms schrieb am 31.Jul.2002:
* Philipp Thomas schrieb am 31 Jul 2002:
Nein, was ich meinte waren abweichende timestamps. Im tarball liegen normalerweise neben den .y Dateien auch die mittels Bison generierten entsprechenden .c Dateien bei. Wenn jetzt nicht entweder alle entsprechenden .c Dateien getouched werden oder aber nicht *alle* .y Dateien neu durch Bison gejagt werden, hast du .c Dateien, die u.U. mit verschiedenen Versionen von Bison generiert wurden.
Hm.. aber das erklärt nicht den Fehler innerhalb einer .yy Datei, oder versteh ich dich falsch?
Sehe ich genauso. Bison hat einen Fehler gemeldet. C hat da nichts mit zu tun. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
B.Brodesser@t-online.de [31 Jul 2002 19:42:56 +0200]:
* Sebastian Helms schrieb am 31.Jul.2002:
Hm.. aber das erklärt nicht den Fehler innerhalb einer .yy Datei, oder versteh ich dich falsch?
Sehe ich genauso. Bison hat einen Fehler gemeldet. C hat da nichts mit zu tun.
Dürfte ich deine Aufmerksamkeit noch einmal auf die Fehlermeldungen lenken? gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include -c ../../gcc/c-parse.c /usr/share/bison.simple:172: conflicting types for `yyparse' ../../gcc/tree.h:2083: previous declaration of `yyparse' Hier hat der Compiler versucht, c-parse.c zu übersetzen, welches aus c-parse.y entsteht. Nicht Bison meldet den Fehler, sondern der Compiler, weil letzterer sich widersprechende Typen für yyparse vorfindet. Ich würde zur Sicherheit ein find . -name \*.y |xargs touch in das Specfile einbauen. Damit wäre sichergestellt, dass alle .y noch einmal mit demselben Bison verarbeitet werden. Philipp -- Philipp Thomas work: pthomas@suse.de Development SuSE Linux AG private: philippt@t-online.de
Moin Philipp, * Philipp Thomas schrieb am 01 Aug 2002:
gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include -c ../../gcc/c-parse.c /usr/share/bison.simple:172: conflicting types for `yyparse' ../../gcc/tree.h:2083: previous declaration of `yyparse'
Hier hat der Compiler versucht, c-parse.c zu übersetzen, welches aus c-parse.y entsteht. Nicht Bison meldet den Fehler, sondern der Compiler, weil letzterer sich widersprechende Typen für yyparse vorfindet. Ich würde zur Sicherheit ein
find . -name \*.y |xargs touch
in das Specfile einbauen. Damit wäre sichergestellt, dass alle .y noch einmal mit demselben Bison verarbeitet werden.
Hm. In den .c-Dateien aus dem tarball steht bison 1.25, den hab ich auch auf dem Rechner. Sprich, die mit bison selber erzeugte .c-Datei ist identisch mit der mitgelieferten ... Könnte es an der bison.simple liegen? Gruß, Sebastian -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.sh/faq/
Am Thu, 1 Aug 2002 05:40:24 +0200 schrieb Sebastian Helms:
* Philipp Thomas schrieb am 01 Aug 2002:
gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include -c ../../gcc/c-parse.c /usr/share/bison.simple:172: conflicting types for `yyparse' ../../gcc/tree.h:2083: previous declaration of `yyparse'
Hier hat der Compiler versucht, c-parse.c zu übersetzen, welches aus c-parse.y entsteht. Nicht Bison meldet den Fehler, sondern der Compiler, weil letzterer sich widersprechende Typen für yyparse vorfindet. Ich würde zur Sicherheit ein
find . -name \*.y |xargs touch
in das Specfile einbauen. Damit wäre sichergestellt, dass alle .y noch einmal mit demselben Bison verarbeitet werden.
Hm. In den .c-Dateien aus dem tarball steht bison 1.25, den hab ich auch auf dem Rechner. Sprich, die mit bison selber erzeugte .c-Datei ist identisch mit der mitgelieferten ...
Könnte es an der bison.simple liegen?
Ich schmeiß das jetzt einfach mal so ein, ohne den thread verfolgt zu haben oder eine Ahnung von compilern zu haben. ---schnipp---- Bison problem under Unix The bison.simple file on many releases will not compile with the options used by the PWLib getdate.y grammar. The options are required to make the date parser thread safe so it is necessary to edit the bison.simple file to fix the problem. The file is usually at /usr/lib/bison.simple but in the tradition of unix could actually be anywhere. We leave it up to you to find it. The code: /* Prevent warning if -Wstrict-prototypes. */ #ifdef __GNUC__ int yyparse (void); #endif should be changed to /* Prevent warning if -Wstrict-prototypes. */ #ifdef __GNUC__ #ifndef YYPARSE_PARAM int yyparse (void); #endif #endif To prevent the incorrect function prototype from being defined. The getdate.y should then produce a getdate.tab.c file that will actually compile. ---schnapp--- Maybe? -- Andreas Meyer http://home.wtal.de/MeineHomepage
Moin Philipp, * Philipp Thomas schrieb am 30 Jul 2002:
Sebastian Helms
[29 Jul 2002 20:00:37 +0200]: Jetzt möchte ich auf 2.4.18 updaten und brauche dafür den gcc 2.95.3.
Versuche es doch mal mit den Paketen für die 7.1, welche du unter ftp://ftp.gwdg.de/pub/linux/suse/people/pthomas/gcc/7.1 findest. Die sollten eigentlich auch unter 7.2 tun.
Hm.. aber die von der 7.2 brauchen die GLIBC_2.2, kann ich die einfach so updaten? und ich hab nur eine 6.3 *g* deshalb nehm ich i.d.R. die aktuellsten srpm's und kompiliere mir die selber. Aber dabei stoß ich z.Zt eben auf besagten Fehler. Gruß, Sebastian -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.sh/faq/
Am Mon, 29 Jul 2002 schrieb Sebastian Helms:
auf meinem - mittlerweile wohl völlig verkorksten *g* - System habe ich in letzter Zeit ein paar Updates eingespielt, und eigentlich läuft auch alles so, wie es soll.
Das System ist ein ehemaliges SuSE 6.3 mit selbst kompilierten vanilla 2.4.3-Kernel, reiserfs, den aktuellen Security-Updates für die 6.4 von SuSE (unter anderem libc.so.6 in der Version GLIBC_2.1.2) und dem gcc 2.95.2 von der 7.1 (?) als rpm installiert.
Wie gesagt, prinzipiell läuft es.
Jetzt möchte ich auf 2.4.18 updaten und brauche dafür den gcc 2.95.3.
Wo steht das? in Documentation/Changes? Auf meiner 7.0 läuft auch nur ein 2.95.2 und ich habe den 2.4.18 damit prima kompiliert bekommen und läuft ohne Probleme.
Ich habe das SRPM von der 7.2 installiert und versuche, das RPM neu zu bauen. Dabei kommen folgende - für mich leider nicht verständliche - Meldungen:
...
ln -s ../../gcc/../libiberty/splay-tree.c splay-tree.c gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include splay-tree.c gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include ../../gcc/graph.c gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include ../../gcc/sbitmap.c gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include ../../gcc/resource.c gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include ../../gcc/hash.c gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -I../../gcc/../include -c ../../gcc/c-parse.c /usr/share/bison.simple:172: conflicting types for `yyparse' ../../gcc/tree.h:2083: previous declaration of `yyparse'
Hast Du Dir die entsprechenden Zeilen mal angeschaut? Vielleicht wird's dann klarer? Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin Christoph, * Christoph Maurer schrieb am 30 Jul 2002:
Am Mon, 29 Jul 2002 schrieb Sebastian Helms:
Jetzt möchte ich auf 2.4.18 updaten und brauche dafür den gcc 2.95.3.
Wo steht das? in Documentation/Changes?
Ja.
Auf meiner 7.0 läuft auch nur ein 2.95.2 und ich habe den 2.4.18 damit prima kompiliert bekommen und läuft ohne Probleme.
Hm.. dann probier ich es mal. Woran machen die das denn fest?
/usr/share/bison.simple:172: conflicting types for `yyparse' ../../gcc/tree.h:2083: previous declaration of `yyparse'
Hast Du Dir die entsprechenden Zeilen mal angeschaut? Vielleicht wird's dann klarer?
#ifdef YYPARSE_PARAM #ifdef __cplusplus #define YYPARSE_PARAM_ARG void *YYPARSE_PARAM #define YYPARSE_PARAM_DECL #else /* not __cplusplus */ #define YYPARSE_PARAM_ARG YYPARSE_PARAM #define YYPARSE_PARAM_DECL void *YYPARSE_PARAM; #endif /* not __cplusplus */ #else /* not YYPARSE_PARAM */ #define YYPARSE_PARAM_ARG void *YYPARSE_PARAM #define YYPARSE_PARAM_DECL #endif /* not YYPARSE_PARAM */ /* Prevent warning if -Wstrict-prototypes. */ #ifdef __GNUC__ YYPARSE_RETURN_TYPE yyparse(YYPARSE_PARAM_ARG) YYPARSE_PARAM_DECL; ^^ das ist 172 #endif #if __GNUC__ > 1 /* GNU C and GNU C++ define this. */ #define __yy_memcpy(TO,FROM,COUNT) __builtin_memcpy(TO,FROM,COUNT) #else /* not GNU C or C++ */ #ifndef __cplusplus Ich habe an bison nichts wissentlich verändert ... die Datei gehört zu bison-1.25.104 Gruß, Sebastian -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.sh/faq/
Am Die, 30 Jul 2002 schrieb Sebastian Helms:
* Christoph Maurer schrieb am 30 Jul 2002:
Am Mon, 29 Jul 2002 schrieb Sebastian Helms:
Jetzt möchte ich auf 2.4.18 updaten und brauche dafür den gcc 2.95.3.
Auf meiner 7.0 läuft auch nur ein 2.95.2 und ich habe den 2.4.18 damit prima kompiliert bekommen und läuft ohne Probleme.
Hm.. dann probier ich es mal. Woran machen die das denn fest?
AFAIK kompiliert der Kernel mit gcc3 noch nicht sauber, das heißt eine Angabe wie gcc 2.x.y or later reicht nicht aus. Da im Kernel Code zum Teil um die Bugs des gcc herum gebastelt wurde, ist er sehr compilersensitiv, das heißt, die Kernel-Entwickler werden sich auf eine voll unterstützte Version festlegen und das ist dann sehr wahrscheinlich die aktuellste gcc-Version, mit der alles funktioniert (i.e. gcc 2.95.3). Das heißt IMHO aber nicht, daß man die unbedingt braucht, wenn es einen Fehler beim Kompilieren des Kernels gibt und man nicht die empfohlene Version verwendet, sollte man aber vielleicht erst mal den entsprechenden Kompiler testen, bevor man sich auf der lkml beschwert...
/usr/share/bison.simple:172: conflicting types for `yyparse' ../../gcc/tree.h:2083: previous declaration of `yyparse'
Hast Du Dir die entsprechenden Zeilen mal angeschaut? Vielleicht wird's dann klarer?
[Die entsprechenden Zeilen]
Habe ich leider auf den ersten Blick nichts gesehen. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Mit, 2002-07-31 um 08.17 schrieb Christoph Maurer:
Am Die, 30 Jul 2002 schrieb Sebastian Helms:
* Christoph Maurer schrieb am 30 Jul 2002:
Am Mon, 29 Jul 2002 schrieb Sebastian Helms:
Jetzt möchte ich auf 2.4.18 updaten und brauche dafür den gcc 2.95.3.
Auf meiner 7.0 läuft auch nur ein 2.95.2 und ich habe den 2.4.18 damit prima kompiliert bekommen und läuft ohne Probleme.
Hm.. dann probier ich es mal. Woran machen die das denn fest?
AFAIK kompiliert der Kernel mit gcc3 noch nicht sauber, das heißt Hier läuft einiges durcheinander - Es war von gcc-2.95.3 und nicht von gcc-3.x die Rede.
eine Angabe wie gcc 2.x.y or later reicht nicht aus. Da im Kernel Code zum Teil um die Bugs des gcc herum gebastelt wurde, ist er sehr compilersensitiv, das heißt, die Kernel-Entwickler werden sich auf eine voll unterstützte Version festlegen und das ist dann sehr wahrscheinlich die aktuellste gcc-Version, mit der alles funktioniert (i.e. gcc 2.95.3). Umgekehrt gilt das Gleiche: Teile des Kernels nutzen Features/Bugs im GCC aus, die, weil in der Zwischenzeit im GCC behoben, nun im Kernel nicht mehr funktionieren (Stichwort: volatile asm)
/usr/share/bison.simple:172: conflicting types for `yyparse' ../../gcc/tree.h:2083: previous declaration of `yyparse'
Hast Du Dir die entsprechenden Zeilen mal angeschaut? Vielleicht wird's dann klarer?
[Die entsprechenden Zeilen] Dies ist ganz eindeutig ein Bug in dem von Dir verwendeten gcc-src.rpm (möglicherweise auch im gcc-tarball selbst), der sich bei Dir in Folge inkompatibler bisons auswirkt.
Hintergrund: Die gcc-Quellen beinhalten die von bison generierten C-Quellen. Normalerweise werden diese bei Übersetzen des gcc nicht neu generiert. Sie werden nur dann neu generiert, wenn sich die Zeitstempel des Yacc-Codes (der *.y-Dateien) oder von Dateien von denen der Yacc-Code abhängt geändert hat. Dies tritt normalerweise nur dann auf, wenn etwas an diesen Dateien verändert wurde - Also entweder editiert oder gepatcht wurde. Letzteres wird in src.rpms oft gemacht und kann dazuführen, dass generierter Code neu erzeugt wurde. Das würde wiederum bedeuten, dass das rpm.spec fehlerhaft ist. Abhilfe: Entweder bison auf eine passende Version umrüsten (Kann bei gcc-2.95.3 auch downgrade bedeuten - Welche Version genau benötigt wird, weiss ich gerade nicht). Theoretisch sollte es möglich sein, den bison aus einere neueren SuSE-Version aufzuspielen oder aber vom src.rpm zu übersetzen. Oder das rpm.spec so zu ändern, dass unmittelbar vor dem configure Aufruf ein contrib/gcc_update --touch ausgeführt wird (Der genaue Pfad kann je nach rpm ein wenig anders aussehen). Danach sollten die Zeitstempel richtig gestellt sein und der bison-Aufruf nicht mehr getriggert werden. Wenn doch, bist Du Opfer eines gcc-Bugs und Dir bleibt nur noch einen passenden Bison zu suchen (Der Tarball liegt irgendwo auf ftp://gcc.gnu.org) Ralf
Am Mit, 31 Jul 2002 schrieb Ralf Corsepius:
Am Mit, 2002-07-31 um 08.17 schrieb Christoph Maurer:
Am Die, 30 Jul 2002 schrieb Sebastian Helms:
* Christoph Maurer schrieb am 30 Jul 2002:
Am Mon, 29 Jul 2002 schrieb Sebastian Helms:
Jetzt möchte ich auf 2.4.18 updaten und brauche dafür den gcc 2.95.3.
Auf meiner 7.0 läuft auch nur ein 2.95.2 und ich habe den 2.4.18 damit prima kompiliert bekommen und läuft ohne Probleme.
Hm.. dann probier ich es mal. Woran machen die das denn fest?
AFAIK kompiliert der Kernel mit gcc3 noch nicht sauber, das heißt Hier läuft einiges durcheinander - Es war von gcc-2.95.3 und nicht von gcc-3.x die Rede.
Mir schon klar, wollte nur erläutern, daß man bei der Compilervorgabe für die Kernelkompilierung nur genau eine Version angeben kann und nicht das vielfach übliche "Version x.y.z or later" Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin Ralf, * Ralf Corsepius schrieb am 31 Jul 2002:
Am Mit, 2002-07-31 um 08.17 schrieb Christoph Maurer:
Am Die, 30 Jul 2002 schrieb Sebastian Helms:
[Die entsprechenden Zeilen] Dies ist ganz eindeutig ein Bug in dem von Dir verwendeten gcc-src.rpm
Oh, wie schön *g* SuSE-7.2 ;-)
Abhilfe: Entweder bison auf eine passende Version umrüsten (Kann bei gcc-2.95.3 auch downgrade bedeuten - Welche Version genau benötigt wird, weiss ich gerade nicht). Theoretisch sollte es möglich sein, den bison aus einere neueren SuSE-Version aufzuspielen oder aber vom src.rpm zu übersetzen.
Unabhängig davon, daß der Kernel auch mit dem 2.95.2 läuft ... Wie kriege ich denn die benötigte Version raus, einfach mal die neueste probieren? Gruß, Sebastian -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.sh/faq/
Am Mit, 2002-07-31 um 17.33 schrieb Sebastian Helms:
Moin Ralf,
* Ralf Corsepius schrieb am 31 Jul 2002:
Am Mit, 2002-07-31 um 08.17 schrieb Christoph Maurer:
Am Die, 30 Jul 2002 schrieb Sebastian Helms:
[Die entsprechenden Zeilen] Dies ist ganz eindeutig ein Bug in dem von Dir verwendeten gcc-src.rpm
Oh, wie schön *g* SuSE-7.2 ;-) Tja, ... ;)
Abhilfe: Entweder bison auf eine passende Version umrüsten (Kann bei gcc-2.95.3 auch downgrade bedeuten - Welche Version genau benötigt wird, weiss ich gerade nicht). Theoretisch sollte es möglich sein, den bison aus einere neueren SuSE-Version aufzuspielen oder aber vom src.rpm zu übersetzen.
Unabhängig davon, daß der Kernel auch mit dem 2.95.2 läuft ...
Wie kriege ich denn die benötigte Version raus, einfach mal die neueste probieren? Wenn Du Glück hast geht's ;)
Ansonsten den im src.rpm enthaltenen gcc-2.95.3-Tarball auspacken, sich das darin enthaltende von bison generierte Quellfile ansehen. gcc/c-parse.c: /* A Bison parser, made from c-parse.y by GNU Bison version 1.25 */ Ralf
Moin Christoph, * Christoph Maurer schrieb am 31 Jul 2002:
Am Die, 30 Jul 2002 schrieb Sebastian Helms:
* Christoph Maurer schrieb am 30 Jul 2002:
Am Mon, 29 Jul 2002 schrieb Sebastian Helms:
Jetzt möchte ich auf 2.4.18 updaten und brauche dafür den gcc 2.95.3.
Auf meiner 7.0 läuft auch nur ein 2.95.2 und ich habe den 2.4.18 damit prima kompiliert bekommen und läuft ohne Probleme.
Hm.. dann probier ich es mal. Woran machen die das denn fest?
Kompiliert ohne Fehler auf Anhieb. Jetzt muß nur noch der Kernel laufen ... *g*
AFAIK kompiliert der Kernel mit gcc3 noch nicht sauber, das heißt eine Angabe wie gcc 2.x.y or later reicht nicht aus. Da im Kernel Code zum Teil um die Bugs des gcc herum gebastelt wurde, ist er sehr compilersensitiv, das heißt, die Kernel-Entwickler werden sich auf eine voll unterstützte Version festlegen und das ist dann sehr wahrscheinlich die aktuellste gcc-Version, mit der alles funktioniert (i.e. gcc 2.95.3). Das heißt IMHO aber nicht, daß man die unbedingt braucht, wenn es einen Fehler beim Kompilieren des Kernels gibt und man nicht die empfohlene Version verwendet, sollte man aber vielleicht erst mal den entsprechenden Kompiler testen, bevor man sich auf der lkml beschwert...
Ahso .. wieder was gelernt.
[Die entsprechenden Zeilen]
Habe ich leider auf den ersten Blick nichts gesehen.
Kennt sich hier keiner mit bison aus? *wunder* Hm.. naja, läuft ja erstmal *g* Gruß, Sebastian -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.sh/faq/
participants (7)
-
Andreas Meyer
-
B.Brodesser@t-online.de
-
Christoph Maurer
-
Philipp Thomas
-
Ralf Corsepius
-
Sebastian Helms
-
Sebastian Wolfgarten