# [solved]gcc-4.1.2 lässt sich nicht mit gcc-4.1.2 compilieren

## Ezekeel

Hallo,

der Titel enthält schon so ziemlich alles was man wissen muss. Ich hab mit gcc-3.4.6 gcc-4.1.2 compilieren können. Anschließend habe ich nach Anleitung:

```

env-update && source /etc/profile

fix_libtool_files.sh 3.4.6

emerge --oneshot -av libtool

emerge -eav system

```

gemacht mit dem Ergebnis, dass gcc alles einwandfrei compiliert bist er zu sich selber kommt wo dann das System einfriert und nach einiger Zeit wieder neu startet. Ich hab so ziemlich alles mir bekannte versucht, ohne Erfolg. Das Forum gibt diesbezüglich auch nicht viel her, daher dieser Thread!

mein emerge --info:

```

Portage 2.1.2.7 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r2, 2.6.20-gentoo-r8 x86_64)

=================================================================

System uname: 2.6.20-gentoo-r8 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

Gentoo Base System release 1.12.9

Timestamp of tree: Sun, 27 May 2007 18:20:01 +0000

dev-java/java-config: 1.3.7, 2.0.32

dev-lang/python:     2.4.4-r4

dev-python/pycrypto: 2.0.1-r5

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.61

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10

sys-devel/binutils:  2.16.1-r3

sys-devel/gcc-config: 1.3.16

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.17-r2

ACCEPT_KEYWORDS="amd64"

AUTOCLEAN="yes"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-O2 -march=k8 -fomit-frame-pointer -pipe"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo"

CXXFLAGS="-O2 -march=k8 -fomit-frame-pointer -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="distlocks metadata-transfer sandbox sfperms strict"

GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo http://ftp6.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp6.uni-erlangen.de/pub/mirrors/gentoo"

LINGUAS="de en"

MAKEOPTS="-j3"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"

USE="X acl acpi aim alsa amd64 apm arts berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus dedicated divx4linux dri dvd dvdr dvdread eds emboss encode esd evo fam firefox foomaticdb fortran gdbm gif gimpprint gpm gstreamer hal iconv icq ipv6 isdnlog jpeg kde kerberos ldap libg++ mad midi mikmod mmx mozilla mp3 mpeg mudflap mysql ncurses network nls nptl nptlonly nvidia ogg opengl openmp oscar oss pam pcre pdf perl png ppds pppd python qt qt3 qt3support qt4 quicktime readline reflection samba sdl session spell spl sse sse2 ssl svg tcpd tiff truetype truetype-fonts type1-fonts unicode videos vorbis wmf xml xorg xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" USERLAND="GNU" VIDEO_CARDS="nvidia"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

```

mein gcc-config -l

```

[1] x86_64-pc-linux-gnu-3.4.6

 [2] x86_64-pc-linux-gnu-3.4.6-hardened

 [3] x86_64-pc-linux-gnu-3.4.6-hardenednopie

 [4] x86_64-pc-linux-gnu-3.4.6-hardenednopiessp

 [5] x86_64-pc-linux-gnu-3.4.6-hardenednossp

 [6] x86_64-pc-linux-gnu-4.1.2 *

```

tja nu und sonst weiss ich auch nicht was noch helfen könnte. Einzig und allein was ich bisher noch nicht versucht habe: Ich habe vor dem -e System auf das 2007er Profil gewechselt?! Das dürfte wohl aber nicht der Ursprung allen übels sein, oder?

----------

## schachti

 *Ezekeel wrote:*   

> 
> 
> mit dem Ergebnis, dass gcc alles einwandfrei compiliert bist er zu sich selber kommt wo dann das System einfriert und nach einiger Zeit wieder neu startet.

 

Was friert ein und startet dann neu? Der PC? Das Kompilieren vom gcc?

----------

## Ezekeel

sorry - der PC friert ein!

----------

## schachti

Sowas ist oft ein Zeichen für ein Hardwareproblem... Sind die Temperaturen (CPU, Gehäuse) ok? Sichtbare Schäden an der Hardware (speziell Elkos auf dem Mainboard)? Hast Du mal für ein paar Stunden memtest laufen lassen?

----------

## Ezekeel

Ich schließe Hardware Probleme deshalb aus weil der PC erst frisch von der Reparatur kommt (Bios war im A*Sch). Ich weiss, dass das kein allzugroßer Indikator dafür ist, dass nun alles passt, gerade nach Reparaturen sind die Dinger kaputt, aber: 

1. Hat der Händler meines Vertrauens die Hardware auf Herz und Nieren nach der Reparatu getestet was ich ihm auch glaube

2. Compiliert ja gcc alles andere, auch die großen Pakete wie kde weshalb man von einem RAM-Defekt oder überhitzung nicht auszugehen hat 

und last but not least

3. Habe ich schon stresstests drüberlaufen lassen die er alle einwandfrei weggesteckt hat

Hoffe mir kann dennoch jemand helfen. Wie gesagt ich habe keinen Plan was da passiert. Ein weiterer Hinweis vielleicht. Wie gesagt der Rechner kam nach einiger Zeit aus der Reparatur, daraufhin hab ich dann ein emerge -uDv world gemacht wo er mir eben gcc-4.1.2 gezogen hat. Nun das seltsame an der Sache ist, dass gcc automatisch auf 4.1.2 geswitched hat ohne dass ich es zuerst gemerkt habe. Erst nach einiger Zeit und einigen compilierten paketen habe ich dann das aus der Anleitung gemacht mit env-update etc. pp. Den Kernel habe ich zwischenzeitlich auch mit dem neuen compiler gemacht. 

Mal ne Anfänger Frage nebenbei - hab zwar schon seit 2 Jahren linux fest, aber wieso macht man fix_libtool_files.sh 3.4.6? müsste das nicht 4.1.2 heissen?!?  

Hoffe auf eure Antworten. Ich könnte ja auch ein --skipfirst nach dem ersten abschmieren machen und dann gcc ausschließen. Aber ich bin nicht so sehr für das fehler umgehen will sie lieber lösen!  :Smile:  Aber zwingend Notwendig ist es doch nicht, dass gcc sich nochmal selber compiliert, oder?

----------

## Psycho Dad

Freezt der PC denn immer an der selben Stelle?

Wenn nicht, ist es wahrscheinlich ein Harwaredefekt.

----------

## kurt

hallo,

hast du genügend freien platz auf der festplatte?

eventuel hilft auch ein emerge binutils -1

gruss

kurt

----------

## Ezekeel

Das kann ich nicht mit absoluter Bestimmtheit sagen, aber ja mit an Sicherheit grenzender Wahrscheinlichkeit friert er immer an der selben Stelle ein - wie gesagt, das Problem tritt nur bei gcc auf, es wäre doch seltsam wenn es da an der Hardware läge, oder?

Das mit den binutils pobier ich morgen aus, bin heute leider nimmer dazu gekommen! Danke vorerst mal für den Tipp!

----------

## Ezekeel

so hab 

```

emerge binutils -1

```

gemacht, mit dem Erfolg, dass nun nicht mehr das System einfriert sondern gcc nun bei 0% CPU Last bei 

```

[...]

Automaton `pentium'

       48 NDFA states,            138 NDFA arcs

       48 DFA states,             138 DFA arcs

       20 minimal DFA states,      82 minimal DFA arcs

      273 all insns         17 insn equivalence classes

   88 transition comb vector els,   340 trans table els: use comb vect

   88 state alts comb vector els,   340 state alts table els: use comb vect

  340 min delay table els, compression factor 2

Automaton `pentium_fpu'

       80 NDFA states,            172 NDFA arcs

       80 DFA states,             172 DFA arcs

       75 minimal DFA states,     162 minimal DFA arcs

      273 all insns          8 insn equivalence classes

  164 transition comb vector els,   600 trans table els: use comb vect

  164 state alts comb vector els,   600 state alts table els: use comb vect

  600 min delay table els, compression factor 1

Automaton `ppro_decoder'

        4 NDFA states,             12 NDFA arcs

        4 DFA states,              12 DFA arcs

        4 minimal DFA states,      12 minimal DFA arcs

      273 all insns          4 insn equivalence classes

   13 transition comb vector els,    16 trans table els: use simple vect

   13 state alts comb vector els,    16 state alts table els: use simple vect

   16 min delay table els, compression factor 8

Automaton `ppro_core'

      105 NDFA states,            376 NDFA arcs

      105 DFA states,             376 DFA arcs

      105 minimal DFA states,     376 minimal DFA arcs

      273 all insns         13 insn equivalence classes

  481 transition comb vector els,  1365 trans table els: use comb vect

  481 state alts comb vector els,  1365 state alts table els: use comb vect

 1365 min delay table els, compression factor 1

Automaton `ppro_idiv'

       38 NDFA states,             79 NDFA arcs

       38 DFA states,              79 DFA arcs

       38 minimal DFA states,      79 minimal DFA arcs

      273 all insns          5 insn equivalence classes

   82 transition comb vector els,   190 trans table els: use simple vect

   82 state alts comb vector els,   190 state alts table els: use simple vect

  190 min delay table els, compression factor 1

Automaton `ppro_fdiv'

       38 NDFA states,             79 NDFA arcs

       38 DFA states,              79 DFA arcs

       38 minimal DFA states,      79 minimal DFA arcs

      273 all insns          5 insn equivalence classes

   82 transition comb vector els,   190 trans table els: use simple vect

   82 state alts comb vector els,   190 state alts table els: use simple vect

  190 min delay table els, compression factor 1

Automaton `ppro_load'

        3 NDFA states,              8 NDFA arcs

        3 DFA states,               8 DFA arcs

        3 minimal DFA states,       8 minimal DFA arcs

      273 all insns          4 insn equivalence classes

    9 transition comb vector els,    12 trans table els: use simple vect

    9 state alts comb vector els,    12 state alts table els: use simple vect

   12 min delay table els, compression factor 4

Automaton `ppro_store'

       16 NDFA states,             56 NDFA arcs

       16 DFA states,              56 DFA arcs

       11 minimal DFA states,      44 minimal DFA arcs

      273 all insns          7 insn equivalence classes

   51 transition comb vector els,    77 trans table els: use simple vect

   51 state alts comb vector els,    77 state alts table els: use simple vect

   77 min delay table els, compression factor 4

Automaton `k6_decoder'

        4 NDFA states,             11 NDFA arcs

        4 DFA states,              11 DFA arcs

        3 minimal DFA states,       9 minimal DFA arcs

      273 all insns          4 insn equivalence classes

   10 transition comb vector els,    12 trans table els: use simple vect

   10 state alts comb vector els,    12 state alts table els: use simple vect

   12 min delay table els, compression factor 8

Automaton `k6_load_unit'

       11 NDFA states,             24 NDFA arcs

       11 DFA states,              24 DFA arcs

       11 minimal DFA states,      24 minimal DFA arcs

      273 all insns          4 insn equivalence classes

   26 transition comb vector els,    44 trans table els: use simple vect

   26 state alts comb vector els,    44 state alts table els: use simple vect

   44 min delay table els, compression factor 2

Automaton `k6_store_unit'

       68 NDFA states,            233 NDFA arcs

       68 DFA states,             233 DFA arcs

       37 minimal DFA states,     126 minimal DFA arcs

      273 all insns          6 insn equivalence classes

  140 transition comb vector els,   222 trans table els: use simple vect

  140 state alts comb vector els,   222 state alts table els: use simple vect

  222 min delay table els, compression factor 1

Automaton `k6_integer_units'

      114 NDFA states,            396 NDFA arcs

      114 DFA states,             396 DFA arcs

      114 minimal DFA states,     396 minimal DFA arcs

      273 all insns         11 insn equivalence classes

  471 transition comb vector els,  1254 trans table els: use comb vect

  471 state alts comb vector els,  1254 state alts table els: use comb vect

 1254 min delay table els, compression factor 1

Automaton `k6_fpu_unit'

       58 NDFA states,            120 NDFA arcs

       58 DFA states,             120 DFA arcs

       57 minimal DFA states,     118 minimal DFA arcs

      273 all insns          5 insn equivalence classes

  120 transition comb vector els,   285 trans table els: use simple vect

  120 state alts comb vector els,   285 state alts table els: use simple vect

  285 min delay table els, compression factor 1

Automaton `k6_branch_unit'

        2 NDFA states,              5 NDFA arcs

        2 DFA states,               5 DFA arcs

        2 minimal DFA states,       5 minimal DFA arcs

      273 all insns          3 insn equivalence classes

    6 transition comb vector els,     6 trans table els: use simple vect

    6 state alts comb vector els,     6 state alts table els: use simple vect

    6 min delay table els, compression factor 8

Automaton `athlon'

      518 NDFA states,           1668 NDFA arcs

      518 DFA states,            1668 DFA arcs

       76 minimal DFA states,     328 minimal DFA arcs

      273 all insns         10 insn equivalence classes

  359 transition comb vector els,   760 trans table els: use simple vect

  359 state alts comb vector els,   760 state alts table els: use simple vect

  760 min delay table els, compression factor 2

Automaton `athlon_load'

      162 NDFA states,            855 NDFA arcs

      162 DFA states,             855 DFA arcs

      162 minimal DFA states,     855 minimal DFA arcs

      273 all insns         10 insn equivalence classes

 1047 transition comb vector els,  1620 trans table els: use simple vect

 1047 state alts comb vector els,  1620 state alts table els: use simple vect

 1620 min delay table els, compression factor 2

Automaton `athlon_mult'

       16 NDFA states,             48 NDFA arcs

       16 DFA states,              48 DFA arcs

       16 minimal DFA states,      48 minimal DFA arcs

      273 all insns          4 insn equivalence classes

   50 transition comb vector els,    64 trans table els: use simple vect

   50 state alts comb vector els,    64 state alts table els: use simple vect

   64 min delay table els, compression factor 2

Automaton `athlon_fp'

    15522 NDFA states,          99908 NDFA arcs

    15522 DFA states,           99908 DFA arcs

      463 minimal DFA states,    3038 minimal DFA arcs

      273 all insns         21 insn equivalence classes

 3057 transition comb vector els,  9723 trans table els: use comb vect

 3057 state alts comb vector els,  9723 state alts table els: use comb vect

 9723 min delay table els, compression factor 1

17533 all allocated states,     102661 all allocated arcs

32710 all allocated alternative states

 6256 all transition comb vector els, 16780 all trans table els

 6256 all state alts comb vector els, 16780 all state alts table els

16780 all min delay table els

    0 locked states num

  transformation: 0.008001, building DFA: 7.196449

  DFA minimization: 0.404026, making insn equivalence: 0.004000

 all automaton generation: 7.740483, output: 0.064004

/bin/sh /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/gcc/../move-if-change tmp-attrtab.c insn-attrtab.c

insn-attrtab.c is unchanged

echo timestamp > s-attrtab

stage1/xgcc -Bstage1/ -B/usr/x86_64-pc-linux-gnu/bin/   -O2 -march=k8 -pipe -fprofile-generate -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute     -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/gcc -I/var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/gcc/. -I/var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/gcc/../include -I/var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/gcc/../libcpp/include     -c insn-attrtab.c \

          -o insn-attrtab.o

```

stehen bleibt?! Ich warte noch ein wenig, fürchte aber, dass sich daran nix mehr änder?!?

----------

## schachti

Vielleicht ein Problem mit der Festplatte und/oder dem Dateisystem?

----------

## Ezekeel

hab erst vor kurzem ein fsck drüberlaufen lassen und das Paket neu runtergeladen!? fsck hat nix gefunden und das Paket entpackt zumindest sauber...  :Sad: 

----------

## Ezekeel

Bin zurzeit auf einer Fortbildung und damit nur noch an den Wochenenden am PC. Habe aber mal 6 Stunden lang memtest über das System laufen lassen und mindestens noch einmal so lange einen BurnIn test. Weiterhin habe ich die Festplatte mit hdparm und smartctrl getestet?! Nirgends kamen dabei Fehler raus. 

Kann es denn daran liegen, dass der PC bei der Reparatur war und dabei der Bios Chip und die Ram getauscht wurden?!? Die Ram wurden von 2T auf 1T erhöht... sind eben so ausgelegt?

Langsam gehts mir auf jeden Fall auf den Senkel wenn alles nichts nutzt mach ich es eben mit Linux so wie mit Windows, einfach neu installieren, auch wenn das hier viel mehr arbeit bedeutet!!!  :Sad: 

----------

## Marlo

 *Ezekeel wrote:*   

> 
> 
> Langsam gehts mir auf jeden Fall auf den Senkel wenn alles nichts nutzt mach ich es eben mit Linux so wie mit Windows, einfach neu installieren, auch wenn das hier viel mehr arbeit bedeutet!!! 

 

Würde ich nicht machen!

Seit heute habe ich das selbe Problem (ohne wsentlichen Hardwarewechsel) und werde noch ein wenig Geduld üben.

Das wird sich schon lösen lassen.

Ma

----------

## Ezekeel

@Marlo hast du zwischenzeitlich eine Lösung gefunden oder stehst du immer noch vor dem selben Problem wie ich? 

Ps. Die glibc lässt sich auch nicht compilieren... alles geht nur nicht gcc und glibc?!? o.O

----------

## treor

das problem kann nicht direkt am gcc 4-1-2 liegen

bei der installation von einem neuen gcc wird der eh mehrmals gebaut bis man am ende eine version auf der platte hat die mit sich selbst gebaut ist

es muss also sich irgendwas ausserhalb vom gcc verändert haben seit du ihn das letzte mal erfolgreich installiert hast

----------

## Ezekeel

nein hat sich eben nicht, das ist ja das verwunderliche... ich wüsste zumindest nicht was!

----------

## Max Steel

So nu melde ich mich auch ma wieder, aber bei mir wird komischerweise 1 mal auf 4.1.2 dann wieder 3.3.6 oder so.

Das is bestimmt nicht normal,oder?

----------

## Finswimmer

 *Max Steel wrote:*   

> So nu melde ich mich auch ma wieder, aber bei mir wird komischerweise 1 mal auf 4.1.2 dann wieder 3.3.6 oder so.
> 
> Das is bestimmt nicht normal,oder?

 

Normal ist eher, dass ich nicht verstehe, was du meinst...   :Rolling Eyes: 

----------

## Max Steel

Naja gut, hätte einen neuen Thread aufmachen sollen, war zu faul.

Ne also, mein PC macht:

```
$ sudo emerge -avuDN system

These are the packages that would be merged, in order:

Calculating system dependencies... done!

[ebuild     U ] sys-devel/gcc-4.1.2 [4.1.1-r3] USE="fortran gcj* nls 

[ebuild     U ] sys-libs/glibc-2.5-r4 [2.5] USE="glibc-omitfp* nls nptl nptlonly

[ebuild   R   ] sys-devel/gcc-3.3.6-r1  USE="fortran gcj* nls 

[ebuild     U ] sys-fs/udev-104-r13 [104-r12]

[ebuild   R   ] sys-apps/module-init-tools-3.2.2-r3

Total: 5 packages (3 upgrades, 2 reinstalls), Size of downloads: 483 kB

Would you like to merge these packages? [Yes/No]

```

(Alle UseFlags die nicht benutzt werden hab ich mal rausgenommen)

Also Reinstalls, keine Downgrades.

----------

## mv

 *Ezekeel wrote:*   

> 
> 
> ```
> 
> [...]
> ...

 

Das ist der Teil des Compilationsprozesses, bei dem mit weitem Abstand der meiste Speicher verbraucht wird (wahrscheinlich sogar mehr als bei so ziemlich jedem anderen Paket). Und da gcc-4.1.* von Haus aus viel speicherhungriger ist als gcc-3.* (und es sich ja offensichtlich um stage1 handelt), wurde bei der ersten Kompilation mit gcc-3.* noch nicht ganz so viel Speicher benötigt.

Ein möglicher Fehler wäre also, dass eines Deiner RAM-Module im "höheren" Speicherbereich bei sehr intensivem Zugriff zu spinnen anfängt. Ein anderer möglicher Fehler wäre, dass Dir schlichtweg der Speicher ausgeht und dies der gcc nicht abfängt (und der Kernel dann anfängt, willkürliche Prozesse abzuschießen). Versuch doch mal den Swap-Speicher deutlich zu erhöhen.

----------

## Finswimmer

 *Max Steel wrote:*   

> Naja gut, hätte einen neuen Thread aufmachen sollen, war zu faul.
> 
> Ne also, mein PC macht:
> 
> ```
> ...

 

Ins Blaue, da ich da keinen Fehler sehe: GCC ist geslotted, das heißt, dass sowohl einen 3er als auch eine 4er Version installiert ist.

Beide können zur gleichen Zeit Updates/Änderungen erfahren: 3er bekommt eine neue Use Flag und die 4er eine neue Version.

Wenn das wirklich deine Frage war, dann würde ich die nochmal das Handbuch zu Portage empfehlen, denn mir scheint es, dass da eine grundlegende Wissenslücke ist.

Tobi

----------

## Max Steel

hmm, okay,

das neue Use-Flag leuchtet mir ein.

HAbe glaub auch ein paar neue.

----------

## Marlo

 *Ezekeel wrote:*   

> @Marlo hast du zwischenzeitlich eine Lösung gefunden oder stehst du immer noch vor dem selben Problem wie ich? 
> 
> Ps. Die glibc lässt sich auch nicht compilieren... alles geht nur nicht gcc und glibc?!? o.O

 

Hallo Ezekeel,

gestern habe ich die /etc/locale.gen aufgeräumt und mit den Einträgen in 

/usr/share/i18n/SUPPORTED verprobt. Ein darauffolgendes emerge glibc

lief problemlos durch worauf hin ich heute morgen ein emerge gcc eingab.

Und siehe da, es geht wieder   :Cool:  .

Grüße

Ma

----------

## Ezekeel

hallo sorry, dass ich schon so lange nicht mehr hier reingeschaut habe - aber der Fehler in gcc und die Faulheit mein System neu zu machen haben mich davon abgehalten weiter nach der Lösung des Problems auf die Suche zu gehen... 

 *Quote:*   

> 
> 
> Das ist der Teil des Compilationsprozesses, bei dem mit weitem Abstand der meiste Speicher verbraucht wird (wahrscheinlich sogar mehr als bei so ziemlich jedem anderen Paket). Und da gcc-4.1.* von Haus aus viel speicherhungriger ist als gcc-3.* (und es sich ja offensichtlich um stage1 handelt), wurde bei der ersten Kompilation mit gcc-3.* noch nicht ganz so viel Speicher benötigt.
> 
> Ein möglicher Fehler wäre also, dass eines Deiner RAM-Module im "höheren" Speicherbereich bei sehr intensivem Zugriff zu spinnen anfängt. Ein anderer möglicher Fehler wäre, dass Dir schlichtweg der Speicher ausgeht und dies der gcc nicht abfängt (und der Kernel dann anfängt, willkürliche Prozesse abzuschießen). Versuch doch mal den Swap-Speicher deutlich zu erhöhen.
> ...

 

Mag sein, ich halte es dennoch für absolut unwahrscheinlich. Ich habe 5 Stunden lang memtest über meine Speicher ohne Fehler laufen lassen. Ausserdem ist es mehr als seltsam, dass der compiler immer an der selben stelle stehen bleibt was wohl bei einem Fehler im Ram nicht so wäre. Denke ich zumindest, es heisst ja nicht um sonst Random Access Memory, ergo belegt er jedesmal einen anderen teil des Speichers und würde jedesmal an ähnlichen, aber nicht immer an der selben Stelle hängen bleiben?! Korrigiert mich wenn ich hier falsch liege?! 

 *Quote:*   

> 
> 
> Hallo Ezekeel,
> 
> gestern habe ich die /etc/locale.gen aufgeräumt und mit den Einträgen in
> ...

 

Ich versuche mal selbst herauszufinden was genau du gemacht hast, allerdings bin ich nicht so sehr der Linux Geek, dass ich wirklich wüsste zu was die Dateien gut sind bzw. was drin sein darf und was nicht. Ich hoffe das Forum und google werden mir hier weiterhelfen - ansonsten wäre ich dir dankbar wenn du mir ein wenig Licht in das Dunkel schicken würdest und vielleicht den Inhalt deiner Datei mal postest?! 

Ansonsten vorerst mal vielen Dank für die Anteilnahme - ich schau mal was sich machen lässt!  :Smile: 

----------

## Marlo

 *Ezekeel wrote:*   

> 
> 
> - ansonsten wäre ich dir dankbar wenn du mir ein wenig Licht in das Dunkel schicken würdest und vielleicht den Inhalt deiner Datei mal postest?! 
> 
> 

 

Zu UTF8 und der locale.gen --> http://de.gentoo-wiki.com/Utf8#.2Fetc.2Flocale.gen

In der Datei /usr/share/i18n/SUPPORTED stehen genau die locale Bezeichnungen drinn, die vom System akzeptiert werden.

```

#

# For the default list of supported combinations, see the file:

# /usr/share/i18n/SUPPORTED

#

# Whenever glibc is emerged, the locales listed here will be automatically

# rebuilt for you.  After updating this file, you can simply run `locale-gen`

# yourself instead of re-emerging glibc.

de_DE.UTF-8 UTF-8

de_DE ISO-8859-1

de_DE@euro ISO-8859-15

en_US.UTF-8 UTF-8

en_GB.UTF-8 UTF-8

en_US ISO-8859-1

en_GB ISO-8859-1

```

Danach den Befehl 

```
locale-gen
```

und/oder emerge glibc ausführen. 

Das war es bei mir. Ja und dann noch emerge gcc.

Grüße

Ma

PS 

Hi Ezekeel,

um einem falschen Eindruck vorzubeugen: Ich kann keinen kausalen Zusammenhang zwischen dem Problem und diesem "Lösungsweg" herstellen.

Ich kann nur schildern, was sich zugetragen hat. Mehr nicht.

----------

## mv

 *Ezekeel wrote:*   

> Ich habe 5 Stunden lang memtest über meine Speicher ohne Fehler laufen lassen.

 

Kompilierprozesse stressen das System deutlich mehr als ein Ramtest. Vor allem, wenn ein Hardwareproblem thermisch bedingt ist, ist es eher die Regel denn die Ausnahme, dass memtest keinen Fehler liefert, Kompilationen aber dennoch mit Fehler abbrechen. Habe ich selbst auch schon so erlebt.

 *Quote:*   

> Ausserdem ist es mehr als seltsam, dass der compiler immer an der selben stelle stehen bleibt was wohl bei einem Fehler im Ram nicht so wäre.

 

Du weißt doch gar nicht, ob der Compiler exakt an der selben Stelle stehen bleibt: Du weißt nur, dass er irgendwo bei der Kompilation der Datei stehen bleibt.

 *Quote:*   

> Denke ich zumindest, es heisst ja nicht um sonst Random Access Memory, ergo belegt er jedesmal einen anderen teil des Speichers und würde jedesmal an ähnlichen, aber nicht immer an der selben Stelle hängen bleiben?!

 

Das englische Wort random hat mehrere Bedeutungen. Es ist hier nicht mit zufällig zu übersetzen sondern eher mit wahlfrei. I.d.R. wird das Betriebssystem nicht exakt reproduzierbar den selben Speicher allozieren, aber doch so ungefähr. Das passt schon insofern mit dem Verhalten zusammen, dass er immer bei der selben stressigen Datei abbricht.

Wieviel Ram hast Du denn? Und wieviel Swap hast Du eingerichtet? Hast Du es jetzt auch wirklich mal mit zusätzlichem Swap-Speicher versucht, etwa mit 

```
dd if=/dev/zero of=/tmp/neuer_swap bs=1K count=1M

mkswap /tmp/neuer_swap

swapon /tmp/neuer_swap
```

(vorausgesetzt, natürlich, Du hast genügend Platz in Deiner /tmp, und dieses ist nicht gerade als Ramdisk gemountet.)

----------

## Ezekeel

Ich glaube der Ursprung allen Übels ist, dass ich meine locales zerschossen habe. Ich hatte in meiner locales.gen nichts stehen, dafür existierte noch meine locales.build, glibc wurde mit der useflage userlocales compiliert und baselayout -unicode. Nun habe ich die locales.gen gefüllt nur habe ich nun das Problem, dass sobald ich eine locale mit utf8 reinmache und danach locale-gen ausführe mein System sofort neu startet. Also habe ich die erst einmal draussen gelassen und glibc ließ sich compilieren. Nach wie vor hängt sich aber das System bei gcc auf. Ich bin noch am werkeln und ausprobieren....

@mv

Ich habe nicht nur memtest über den Speicher laufen lassen sondern auch schon ca. 5 Stunden mit dem Speicher Pakete compiliert ohne dass das System einmal hängen geblieben wäre oder irgend eine Fehlermeldung aufgetaucht wäre die auf einen Hardwaredefekt hätte schließen lassen. Einen BurnIn Test habe ich auch kurz nach erhalt des Systems ohne Fehler drüberlaufen lassen. All das veranlasst mich dazu bei meinem System auf Fehlersuche zu gehen anstelle bei meiner Hardware bei der ich mit 99%iger Sicherheit sagen kann, dass sie in Ordnung ist!

----------

## Ezekeel

Hallo, ich setz jetzt mal den Thread auf solved, glibc und gcc lassen sich nun einwandrei compilieren ohne errors und ohne freezes. Wieso das so lange gedauert hat? Nun ja ich habe mehrere PCs und wenn das auch mein hauptsächlicher ist wollte ich es nicht wahr haben, dass es an der Hardware liegt. Glaube ich ehrlich gesagt nach wie vor nicht so unbedingt. 

Was ich gemacht habe: Ich habe die RAM von Slot 2 u. 4 auf 1 u. 3 getauscht. Ausserdem habe ich die Dram Voltage innerhalb der angegeben Spanne von OCZ von 2.6V auf 2.7 erhöht. Was nun letztendlich der Auslöser war, das tauschen der Slots oder die Spannung, keine Ahnung! Tatsache ist wohl, dass das Board recht aggressiv ist (DFI Lanparty nf4 Ultra) und die RAM ebenso aggressiv anspricht (OCZ 2x1024). Ich habe schon öfters miterelebt, dass Linux bei Gamerkomponenten wie denen öfters rumzickt was wohl daran liegen mag, dass die Ursprünge von Linux im Serverbereich und nicht im Gamerbereich liegen. Ich möchte niemandem die Schuld zuweisen, letztlich bin ich auch viel zu froh darüber, dass es Linux gibt, aber mir fällt es immer noch schwer zu glauben, dass gentoo eine höhere Speicherlast erzeugt, als ein Burn-In Test und memtest die die Ram als Fehlerfrei angezeigt haben. Letztlich kann es an der Spannung gelegen haben...?!? HTH für die die ähnliche Probleme haben!  :Wink: 

Ps.: Danke an alle die sich an dem Thread beteiligt haben!!!

Pss.: Es waren nur die Slots... hab die Spannung auf 2.6V zurückgeschraubt und er compiliert gcc immer noch!

----------

