PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Ständige Segfaults beim kompilieren



Lawless
03.11.03, 20:42
Hallo alle zusammen...

Ich habe mich die letzten Tage schon durchs halbe Web gegooglet und auch hier im Forum habe ich bereits quergelesen, allerdings finde ich nichts passendes.

Ich versuche mich seit einer Woche daran ein Gentoo 1.4 auf mein System zu bekommen. Nach anfänglichen Schwierigkeiten mit meinem Raid Controller hat dies dann auch geklappt - nur habe ich momentan ein recht großes und leider noch nicht ganz nachzuvollziehendes Problem.
Folgender Fehler tritt auf dem gleichen System mit zwei unterschiedlichen Gentoo und einer RedHat Installation auf:
Kompiliere ich einen größeren Source, so habe ich in unregelmäßigen Abständen und meist an komplett unterschiedlichen Stellen segfaults á la Internal Compiler Error: Segmentation Fault Error 2 und Ende...
Führe ich das make einfach nochmal aus, kompiliert er an der betreffenden Stelle weiter... bis er irgendwann wieder an einer anderen aussteigt...
Das ist ziemlich nervig - die Binaries sind aber trotzdem komplett in Ordnung... also auch mein selbst kompilierter Kernel rennt ohne Probleme trotz mehrerer segfaults.

Problematisch wird es erst unter Gentoo mit dem schönen Befehl emerge, denn der hat die Angewohnheit immer ein make clean vor dem Kompilieren zu machen und somit fange ich bei jeden Error von vorne an (seit 2 Tagen sitze ich an xfree und hab noch 50 Packages vor mir!)
Es ist wie russisches Rullett... wie weit kommt er diesmal, ah fast am Ende.... jaja.... Error.....
Wenn ich emerge laufen lasse bis er die Sourcen entpackt hat, alle Patches applied, dann aber abbreche um manuell zu kompilieren, kann ich es ja wieder mit mehrfachem make Aufruf machen.... aber emerge merkt davon nix und denkt, trotz anschließendem make install, das Paket wär nicht drauf und wills nochmal machen...

Habe heute meinen Ram ausgetauscht - keine Besserung. Habe die CPU heruntergetaktet - nix. Habe alle möglichen Timings runtergesetzt... das Ding kriecht jetzt also vor sich hin - immer noch segfaults.... WORAN kann es denn noch liegen?? Was soll ich denn noch machen?? Heul.....

Gibt es denn wenigstens eine Möglichkeit emerge klar zu machen dass die (manuell installierten) Packages da sind, so dass er sie nicht jedesmal neu machen will?
Es ist eine Qual.....

Ich hoffe man kann mir vielleicht helfen. Bin für Tipps in alle Richtungen dankbar....

Mein System:

Athlon XP 1700+ @ 2200+ (oder eben auch @1700+...)
Abit KR7A-Raid
512 MB DDR (ausgetauscht gegen neuen Infineon 256MB)

GCC ist Version 3.2.3 und an Flags ist im mom nur ein march=Athlon-xp gesetzt, sowie dieses 02 wobei ich nich weiß für was das gut is...

Thx in advance

Hun
03.11.03, 20:51
O2 gibt den Optimierungsgrad an, je höher desto schneller und desto geringer ist die Wahrscheinlichkeit von lauffähigem code... verwende O3

date mal python ab, das hat bei mir Zicken verursacht, gleich danach am besten ncoh Portage

Thomas Engelke
03.11.03, 22:07
Ich würd's mal mit Abschalten von ACPI versuchen. Das hat mir geholfen.

AD!

Lawless
04.11.03, 06:06
ACPI is im Kernel aus...

Weil ich gcc 3.2.3 hab und jemand meinte 3.3 wäre die neueste, hab ich ein emerge --update gcc gemacht und da hat er dann erstmal haufenweise Sachen erneuert (sogar die bash! :confused: )
gcc selbst blieb dann natürlich wieder mit segfault stehen :(
Python muss ich mal gucken was ich da für ne Version hab...

Thomas Mitzkat
04.11.03, 06:26
so ein problem hatte ich mal bei einem LFS. ich glaube da haben im grundsystem die compiler-optionen nicht gestimmt, vor allem für gcc und glibc, die ohne extra-optionen kompiliert werden:

http://lfs.crash404.com/lfs/downloads/stable/LFS-BOOK-4.1-HTML.tar.bz2

DarkSorcerer
04.11.03, 07:21
Nicht nur zu starke Optimierung sondern auch der gcc 3.3 könnten die Probleme verursachen. Ich fahre mit O2 Optimierung und hatte bisher kein einziges Problem was das Kompilieren von Code angeht.

Ich habe die CFLAGS für meinen P4 von dieser Seite:
http://www.freehackers.org/gentoo/gccflags/flag_gcc3.html

Dies sind "safe flags" und auf korrekten Code ausgelegt... sicherlich kann man noch weiter tunen, allerdings muss man dann mit Fehlern im code rechnen, was einem Linux system nicht gut tut...

rumpel
04.11.03, 22:30
Das Problem kommt mir irgentwie verdammt bekannt vor: Hatte ich vor ca 4/5 Jahren als ich meinen 133mhz Rechner auf 166Mhz übertaktet hatte, trifft genau die gleiche beschreibung drauf zu. Hab immer 10 Anläufe gebraucht um nen Kernel zu konfigurieren.. Will sagen: Vielleicht Prozessor nichgt gut belüftet, irgentwas übertaktet / falsch eingestellt, klemmt nen lüfter oder so ?

Mfg, Rumpel.

Lawless
05.11.03, 05:55
CPU läuft seit letzten Hoch-Hochsommer mit guten Temperaturen - er kam unter Last (Video codieren o.ä.) nie über 50 Grad.
Auch hatte ich ihn gestern statt als 2200+, als 1500+ *schnief* laufen.... keine Besserung. Da ich den Ram schon ausgetauscht hatte, wäre natürlich nächster Schritt, die CPU zu testen, aber ich kann ja nicht einfach den Duron, der bei mir noch rumfliegt einsetzen - das komplette System ist mit march=athlon-xp gemacht...
Und wie beim Ram, eben mal schnell zum Händler um ne TestCPU zu kaufen.... das wird mit dem Zurückgeben nix :(
Werd mich heut mittag wieder dransetzen.
Bin momentan dabei das Xfree bzw das KDE mehr oder minder manuell drauf zu machen. Statt emerge eben ebuild und dann die make Schritte von Hand. Das zieht sich zwar sehr in die Länge, aber so komm ich vielleicht noch ans Ziel.
Für neues Mainboard, neue CPU, neues Netzteil, neue Festplatte und was es sonst noch alles sein könnte, fehlt das Geld und die Lust.......

almoeli
05.11.03, 10:02
Hi,

also ich hatte dieses Problem auch mal. Es lag am RAM. Allerdings war nicht der RAM-Riegel defekt, sondern die Einstellungen im BIOS haben nicht gepaßt. Alos überprüfe bitte folgendes:
Die Timings stimmen (bei automatischer Konfiguration setz die Timings mal von Hand auf konservative Werte (3-3-3))
Wenn du einen Via Chipsatz hast, so kontrolliere auf jeden Fall die Command Rate und setzt diese um. Das war bei mir nämlich der Grund. Ich weiß jetzt allerdings ob man die auf 1 oder 0 oder 2 setzen muß. Ich glaube aber auf 2.

Gruß

almoelil

Lawless
05.11.03, 14:52
Habs gestern mit den BIOS Setup Defaults bzw Safe Defaults versucht...
Im moment lass ich unter Windows SuperPI durchlaufen... also das Ding berrechnet die PI Nachkommastellen und stresst vor allem die CPU. Da ich den Ram ja schon ausgetauscht hatte....

Lawless
07.11.03, 06:07
Habe seit gestern abend einen alten Duron 800 im System - mehrmaliges Kernel Kompilieren ohne jeden Fehler....
Mein Athlon wird heute zum Händler geschickt - hab schon Ersatz aushandeln können....
Das nächste Mal, wenn ich einen Rechner wirklich testen will, ob alles geht, weiß ich jetzt was ich tun muss ;)