# Systemumstellung auf gcc 3.4(.4)

## amne

Es ist soweit, gcc 3.3.4 wird auf x86 stable, siehe GCC-3.4 will be marked stable in ~1 hour on x86 und die dortigen Links.

Die reine Installation von gcc 3.4.4 hat keinen Einfluss auf das System, man muss selbst die Umstellung auf diesen durchführen. Da dieser Schritt einige Zeit beanspruchen kann ist es empfehlenswert sich entsprechend Zeit zu nehmen und darauf vorzubereiten.

Es gibt zwei mögliche Wege: Ein schneller und ein etwas gründlicherer, der jedoch mehr Zeit in Anspruch nimmt. Der schnelle verwendet revdep-rebuild und es besteht die Möglichkeit, dass Pakete übersehen werden. In diesem Fall müssen sie manuell neu gebaut werden.

Alternative 1: Mit Hilfe von revdep-rebuild (schnell)

Falls nicht bereits vorhanden muss gentoolkit installiert werden. Danach wird die neue gcc-Version installiert und der neue Compiler ausgewählt.

```

# emerge -an gentoolkit

# emerge -uav gcc

# gcc-config i686-pc-linux-gnu-3.4.4

# source /etc/profile

```

Anmerkung: Dieses Beispiel geht von CHOST="i686-pc-linux-gnu" aus. Falls ein anderer gesetzt ist bitte entsprechend anpassen.

Warnung: Bitte jetzt noch keine neuen, nur von gcc 3.4 unterstützten CFLAGS wie -march=pentium-m setzen, falls nocheinmal gcc 3.3.6 übersetzt wird geht das nämlich daneben. 3.4.4 kennt "mcpu=" nicht mehr, stattdessen sollte -march oder -mtune verwendet werden.

Einige Pakete müssen neu uebersetzt werden. Mit Hilfe von revdep-rebuild lassen wir eine Liste dieser Pakete erstellen. Anschließend emergen wir sie neu, auch das erledigt revdep-rebuild für uns.

```
# revdep-rebuild --library libstdc++.so.5 -- -p -v

# revdep-rebuild --library libstdc++.so.5
```

Falls Probleme mit nicht existierenden Versionen (veraltet oder maskiert) auftreten kann auch -X verwendet werden. Damit werden Pakete nur aufgrund ihres Namens, nicht aber die exakt selben Versionen ausgewählt.

```
# revdep-rebuild -X --library libstdc++.so.5 -- -p -v

# revdep-rebuild -X --library libstdc++.so.5
```

Vor dem Entfernen von gcc 3.3.6 muss sys-libs/libstdc++-v3 installiert werden, ansonsten funktionieren manche Anwendungen nicht mehr.

```
# emerge --oneshot sys-libs/libstdc++-v3

# emerge -aC =sys-devel/gcc-3.3*
```

Alternative 2: Mit Hilfe von emerge -e (gründlichere Methode)

Diese Methode nimmt deutlich mehr Zeit in Anspruch. Dafür wird das ganze System mit dem neuen Compiler übersetzt. Zuerst wird gcc upgedated und der neue Compiler ausgewählt.

```
# emerge -uav gcc

# gcc-config i686-pc-linux-gnu-3.4.4

# source /etc/profile
```

Anmerkung: Dieses Beispiel geht von CHOST="i686-pc-linux-gnu" aus. Falls ein anderer gesetzt ist bitte entsprechend anpassen.

Warnung: Bitte jetzt noch keine neuen, nur von gcc 3.4 unterstützten CFLAGS wie -march=pentium-m setzen, da nocheinmal gcc 3.3.6 übersetzt wird und dies zu Fehlern führen würde. 3.4.4 kennt "mcpu=" nicht mehr, stattdessen sollte -march oder -mtune verwendet werden.

Die Bibliothem sys-libs/libstdc++-v3 muss installiert werden um die Kompatibilität mit Binärpaketen, die gegen gcc 3.3 installiert wurden zu sichern.

```
# emerge --oneshot sys-libs/libstdc++-v3
```

Jetzt werden zuerst alle in system, dann alle in world enthaltenen Pakete neu gebaut. Das kann je nach Anzahl der installierten Pakete relativ lange dauern. Dabei wird die Toolchain und alle zugehörigen Files neu gebaut, dann alle Pakete aus dem Systemprofil und schliesslich nocheinmal alle Pakete (inklusive der Toolchain). Damit wird sichergestellt, dass alle Pakete (inklusive der Toolchain) mit der neuen Toolchain gebaut wurden.

```
# emerge -e system 

# emerge -e world
```

Nun kann gcc 3.3.6 entfernt werden

```
# emerge -aC =sys-devel/gcc-3.3*
```

Hinweise/Probleme:

Kernelmodule (z.B. app-emulation/qemu-softmmu), die mit dem neuen gcc 3.4.4 übersetzt wurden funktionieren nicht mit dem alten Kernel. Lösung: Auch diesen mit 3.4.4 neu übersetzen.

Revdep-rebuild will eventuell auch schon neu gebaute Pakete erneut übersetzen (ist mir z.B. mit audacity, wxGTK passiert). Ich habe einfach weitergemacht, Audacity funktioniert noch immer.

Bei Fehlern bei emerge -e system/world kann man mit emerge --resume dort weitermachen, wo abgebrochen wurde. Falls sich das eigentliche Problem nicht lösen lässt kann man dieses Paket mit emerge --resume --skipfirst überspringen.  Man sollte in der Zwischenzeit kein anderes Emerge ausführen, da dann die Information zum Fortsetzen verloren geht.

Dieser Fehler

libtool: link: `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la' is not a valid libtool archive

kann mittels /sbin/fix_libtool_files.sh 3.3.6 beseitigt werden.

Falls /sbin/fix_libtool_files.sh beim Entfernen von gcc 3.3.6 verloren gegangen ist, sollte gcc (3.4.4) nocheinmal gemerged werden. Dies passiert möglicherweise nach emerge -e system falls gcc 3.3.6 nach 3.4.4 gebaut wird. 

Wer gcc nicht nocheinmal mergen will kann /lib/rcscripts/awk/fixlafiles.awk and /sbin/fix_libtool_files.sh aus /usr/portage/sys-devel/gcc/files(/awk) herüberkopieren. Das kann allerdings zur Folge haben, dass Portage diese Files nicht erkennt und sich beim nächsten gcc-Upgrade beschwert falls man collision-protect in den Features aktiviert hat.

Ich hatte vorher gcc 3.3.6, es traten aber Fehler über ein fehlendes /etc/env.d/gcc/i686-pc-linux-gnu-3.3.5 auf.

 *Quote:*   

> # gcc-config -l
> 
> /usr/bin/gcc-config: line 632: /etc/env.d/gcc/i686-pc-linux-gnu-3.3.5: No such
> 
> file or directory
> ...

 

Das Problem wird scheinbar durch ein vergessenes /etc/env.d/gcc/config-i686-pc-linux-gnu mit dem Inhalt "CURRENT=i686-pc-linux-gnu-3.3.5" ausgelöst.

Wer ein solches /etc/env.d/gcc/config-i686-pc-linux-gnu hat (welches nur verwendet wird, falls ein Cross-compiler im Einsatz ist): Datei löschen, compiler neu mit gcc-config setzen und source /etc/profile ausführen.

----------

## Diskus

Hallo,

mache gerade die Umstellung habe aber eine Frage:

während "emerge -e system" wird der gcc-3.3.6 ja noch mal neu gemergt jetzt steht unter "emerge --info" wieder:

Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 2.6.13-gentoo-r3 i686)

usw.

ist das normal??

Diskus

----------

## amne

Hast du den richtigen Gcc als Default-compiler ausgwählt? Wenn ja hat 3.4.4 bei gcc-config -l ein Sternchen. Falls das der Fall ist kannst du vermutlich damit rechnen, dass bei dir das oben beschriebene Problem mit /sbin/fix_libtool_files.sh auftritt wenn du 3.3.6 entfernst.  :Wink: 

----------

## Diskus

Hallo,

ein gcc-config -l bringt:

ocalhost lars # gcc-config -l

 [1] i686-pc-linux-gnu-3.3.6 *

 [2] i686-pc-linux-gnu-3.3.6-hardened

 [3] i686-pc-linux-gnu-3.3.6-hardenednopie

 [4] i686-pc-linux-gnu-3.3.6-hardenednopiessp

 [5] i686-pc-linux-gnu-3.3.6-hardenednossp

 [6] i686-pc-linux-gnu-3.4.4

 [7] i686-pc-linux-gnu-3.4.4-hardened

 [8] i686-pc-linux-gnu-3.4.4-hardenednopie

 [9] i686-pc-linux-gnu-3.4.4-hardenednopiessp

 [10] i686-pc-linux-gnu-3.4.4-hardenednossp

  also ist bei dem emerge -e system der gcc wieder umgestellt worden!

während des neumergen des Systems ist zuerst gcc 3.4.4 und dannach gcc 3.3.6 gemergt worden -ist das nun gut oder schlecht???-ich bin noch bei emerge -e system soll ich abbrechen oder weitermachen lassen?

ich habe mal:emerge -pve sytem gemacht und den ausdruck bekommen:

localhost lars # emerge -pve system

These are the packages that I would merge, in order:

Calculating system dependencies ...done!

[ebuild  N    ] sys-devel/patch-2.5.9  -build -static 0 kB

[ebuild  N    ] sys-libs/gpm-1.20.1-r4  -emacs (-selinux) 0 kB

[ebuild  N    ] sys-libs/ncurses-5.4-r6  -bootstrap -build -debug -doc +gpm -minimal -nocxx -unicode 0 kB

[ebuild  N    ] sys-devel/binutils-config-1.8-r6  0 kB

[ebuild  N    ] sys-devel/gnuconfig-20050602  0 kB

[ebuild  N    ] sys-devel/binutils-2.16.1  -multislot -multitarget +nls -test 0 kB

[ebuild  N    ] sys-devel/m4-1.4.3  +nls 0 kB

[ebuild  N    ] sys-devel/bison-1.875d  +nls -static 0 kB

[ebuild  N    ] sys-apps/sed-4.1.4  -bootstrap -build +nls -static 0 kB

[ebuild  N    ] sys-devel/gcc-config-1.3.12-r4  0 kB

[ebuild  N    ] sys-libs/zlib-1.2.3  -build 0 kB

[ebuild  N    ] sys-devel/gcc-3.4.4-r1  (-altivec) -bootstrap -boundschecking -build +fortran -gcj +gtk -hardened -ip28 -mudflap (-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc -objc-gc -vanilla 0 kB

[ebuild  N    ] sys-devel/gcc-3.3.6  (-altivec) -bootstrap -boundschecking -build +fortran -gcj +gtk -hardened -ip28 -mudflap (-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc -objc-gc -vanilla 0 kB

[ebuild  N    ] sys-kernel/linux-headers-2.6.11-r2  0 kB

[ebuild  N    ] sys-libs/glibc-2.3.5-r2  -build -erandom -glibc-compat20 -glibc-omitfp -hardened -linuxthreads-tls (-multilib) +nls -nptl -nptlonly -pic -profile (-selinux) +userlocales 0 kB

also zuerst wird der 3.4.4-r1 installiert und dannach der gcc 3.3.6-nach der Installation des gcc wir ja gleich automatisch (gcc-config i686-pc-linux-gnu-3.......)geswicht zu der jeweiligen Version.

Diskus

----------

## SinoTech

 *Diskus wrote:*   

> 
> 
> [...]
> 
> also zuerst wird der 3.4.4-r1 installiert und dannach der gcc 3.3.6-nach der Installation des gcc wir ja gleich automatisch (gcc-config i686-pc-linux-gnu-3.......)geswicht zu der jeweiligen Version.
> ...

 

Bin mir ziemlich sicher das NICHT automatisch geswitcht wird. Das musst du schon übernehmen.

Also, da du den neuen gcc ja anscheinend schon installiert hast, wechselt du jetzt zu ihm:

```

$ gcc-config i686-pc-linux-gnu-3.4.4

```

Mit Hilfe von "gcc-config -l" schaust du vorsichtshalber nach ob wirklich der neue Compiler ausgwählt wurde.

Dann machst du

```

$ source /etc/profile

```

Dann baust du dein System neu

```

$ emerge -e system

```

etc. etc. .. wie es eben oben in der Anleitung beschrieben steht.

Mfg

SinoLast edited by SinoTech on Sat Dec 03, 2005 9:29 am; edited 1 time in total

----------

## amne

Ich fürchte da ist etwas beim Umschalten schiefgegangen und du hast alles nochmal mit dem alten Compiler gebaut.

Sprich: nocheinmal gcc-config i686-pc-linux-gnu-3.4.4 und source /etc/profile ausführen und neu emerge -e system/world ausführen.  :Sad: 

Am Besten überprüfst du direkt davor nocheinmal ob gcc-config -l jetzt das * beim 3.4.4 hat.

----------

## Diskus

Hallo,

ich habe jetzt noch mal!!!:

gcc-config i686-pc-linux-gnu-3.4.4 uns source /etc/profile/ gemacht und ein gcc-config -l bringt jetzt:

1] i686-pc-linux-gnu-3.3.6

 [2] i686-pc-linux-gnu-3.3.6-hardened

 [3] i686-pc-linux-gnu-3.3.6-hardenednopie

 [4] i686-pc-linux-gnu-3.3.6-hardenednopiessp

 [5] i686-pc-linux-gnu-3.3.6-hardenednossp

 [6] i686-pc-linux-gnu-3.4.4 *

 [7] i686-pc-linux-gnu-3.4.4-hardened

 [8] i686-pc-linux-gnu-3.4.4-hardenednopie

 [9] i686-pc-linux-gnu-3.4.4-hardenednopiessp

 [10] i686-pc-linux-gnu-3.4.4-hardenednossp

also alles richtig aber mal sehen wenn er den gcc 3.3.6 neu gemerget hat!

DiskusLast edited by Diskus on Sat Dec 03, 2005 11:11 am; edited 1 time in total

----------

## Diskus

Hallo,

und er schwicht doch von allein!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

der Beweis:

-- !targe sym /usr/i686-pc-linux-gnu/gcc-bin/3.3.6/i686-pc-linux-gnu-gcc-3.3.6

--- !targe sym /usr/i686-pc-linux-gnu/gcc-bin/3.3.6/gcc

--- !targe sym /usr/i686-pc-linux-gnu/gcc-bin/3.3.6/g77

--- !targe sym /usr/i686-pc-linux-gnu/gcc-bin/3.3.6/g++

--- !targe sym /usr/i686-pc-linux-gnu/gcc-bin/3.3.6/c++

--- !targe sym /usr/bin/i686-pc-linux-gnu-gcc-3.3.6

--- !targe sym /usr/bin/i686-pc-linux-gnu-g77-3.3.6

--- !targe sym /usr/bin/i686-pc-linux-gnu-g++-3.3.6

--- !targe sym /usr/bin/i686-pc-linux-gnu-c++-3.3.6

--- !targe sym /usr/bin/gcc-3.3.6

--- !targe sym /usr/bin/g77-3.3.6

--- !targe sym /usr/bin/g++-3.3.6

--- !targe sym /usr/bin/c++-3.3.6

>>> original instance of package unmerged safely.

* Switching native-compiler to i686-pc-linux-gnu-3.3.6 ...                                                                                          [ ok ]

 * If you intend to use the gcc from the new profile in an already

 * running shell, please remember to do:

 *   # source /etc/profile

 * If you have issues with packages unable to locate libstdc++.la,

 * then try running 'fix_libtool_files.sh' on the old gcc versions.

>>> Regenerating /etc/ld.so.cache...

>>> sys-devel/gcc-3.3.6 merged.

und sofort kommt unter:

localhost lars # gcc-config -l

 [1] i686-pc-linux-gnu-3.3.6 *

 [2] i686-pc-linux-gnu-3.3.6-hardened

 [3] i686-pc-linux-gnu-3.3.6-hardenednopie

 [4] i686-pc-linux-gnu-3.3.6-hardenednopiessp

 [5] i686-pc-linux-gnu-3.3.6-hardenednossp

 [6] i686-pc-linux-gnu-3.4.4

 [7] i686-pc-linux-gnu-3.4.4-hardened

 [8] i686-pc-linux-gnu-3.4.4-hardenednopie

 [9] i686-pc-linux-gnu-3.4.4-hardenednopiessp

 [10] i686-pc-linux-gnu-3.4.4-hardenednossp

und nun???????

Diskus

----------

## SinoTech

Also habe mal testweise wieder einen älteren gcc intstalliert, und bei mir switcht er nicht:

```

* The current gcc config appears valid, so it will not be

 * automatically switched for you. If you would like to

 * switch to the newly installed gcc version, do the

 * following:

 * gcc-config i686-pc-linux-gnu-3.4.4

 * source /etc/profile

 * Switching native-compiler to i686-pc-linux-gnu-4.0.2 ...

 * If you have issues with packages unable to locate libstdc++.la,

 * then try running 'fix_libtool_files.sh' on the old gcc versions.

 * You should make sure to rebuild all your C++ packages when

 * upgrading between different versions of gcc. For example,

 * when moving to gcc-3.4 from gcc-3.3, emerge gentoolkit and run:

 * # revdep-rebuild --library libstdc++.so.5

```

Ok, habe den 3.4.4 neu installiert und nicht den 3.3.6, aber sollte eigentlich keinen Unterschied machen. Also ich empfehle dir jetzt folgendes:

1. Emerge gcc-3.4.4

2. Switche zu ihm

```

$ gcc-config -l

$ gcc-config <number of your desired compiler>

$ source /etc/profile

```

3. Toolchain neu compilieren

```

$ emerge glibc binutils && emerge glibc binutils gcc

```

4. emerge "libstdc++-v3"

```

$ emerge libstdc++-v3

```

5. deinstalliere den alten gcc (Der wird jetzt nicht mehr gebraucht, da du die libstdc++-v3 hast)

```

$ emerge -C "=gcc-<old-version>

```

6. Baue dein System neu

```

$ emerge -e world

```

In diesem Fall wird der alte gcc nicht neu gebaut, und daher sollte es auch keine Probleme mehr diesbezüglich geben  :Smile: 

Mfg

Sino

EDIT:

Natürlich muss nun noch der Kernel neu gebaut werden, da dieser nur kernelmodule lädt die mit dem gleichen gcc wie er erstellt wurden. Da wir ein "emerge -e world" gemacht haben, wurden natürlich auch solche Packete neu ge-merged die kernelmodule mit sich bringen (Bsp.: das nvidia-Modul).

Also -> Kernel neu bauen.

Danke an schmutzfinger der uns daran erinnert hat.Last edited by SinoTech on Tue Dec 06, 2005 4:29 pm; edited 2 times in total

----------

## Diskus

Hallo,

danke ,das teste ich gleich mal

diskus

----------

## amne

Seltsam. Du hast nicht zufällig ein File namens /etc/env.d/gcc/config-i686-pc-linux-gnu auf deinem System? Wenn ja, welchen Inhalt hat es? Keine Sorge wenn es nicht da ist, eigentlich sollte es nicht existieren.

edit: Bei manchen wird schon bei der Installation von 3.4.4 automatisch auf diesen umgeschalten, bei manchen einscheinend nicht. Bug 114341 geht dieser Sache gerade auf den Grund.

----------

## amne

 *SinoTech wrote:*   

> 
> 
> 2. Switche zu ihm
> 
> 3. Toolchain neu compilieren
> ...

 

Du meinst vermutlich emerge -e world, oder? Abgesehen davon ist diese Methode vermutlich sinnvoller, wir unterhalten uns gerade darüber die Anleitung in diese Richtung abzuändern.

----------

## Diskus

Hallo,

@amne 

die gesuchte datei /etc/env.d/gcc/config-i686-pc-linux-gnu habe ich nicht auf meinen System-ich mache jetzt nach SinoTech ś Anleitung mal weiter

Diskus

----------

## amne

Wie es aussieht wechselt der der Default-compiler auf manchen Systemen von selbst auf manchen nicht. Warum das so ist - keine Ahnung.

In Kürze wird die Methode ähnlich zu Sinos geändert werden, voraussichtlich wird libstdc++-v3 vorgezogen, dann emerge -e system/world (da libstdc++-v3 installiert ist wird 3.3.x niccht mehr gebaut).

----------

## SinoTech

 *amne wrote:*   

> [...]
> 
> Du meinst vermutlich emerge -e world, oder?
> 
> [...]
> ...

 

Jep, habs schon verbessert  :Smile: .

 *amne wrote:*   

> [...]
> 
>  Abgesehen davon ist diese Methode vermutlich sinnvoller, wir unterhalten uns gerade darüber die Anleitung in diese Richtung abzuändern.

 

Damn, I am good!  :Very Happy: 

Ach ja, dann empfehl ich aber aus 4. das hier zu machen:

```

4a. emerge "libstdc++-v3" 

4b. env-update

```

Da die "libstdc++.so.5" nun nicht mehr in diesem verzeichniss liegt:

```

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/

```

sondern in diesem

```

/usr/lib/libstdc++-v3/

```

Mfg

Sino

----------

## amne

 *SinoTech wrote:*   

> Ach ja, dann empfehl ich aber aus 4. das hier zu machen:
> 
> ```
> 
> 4a. emerge "libstdc++-v3" 
> ...

 

Ich bin mir zwar auch nicht sicher, aber solange man gcc 3.3.x noch nicht entfernt hat (was in der gerade geänderten Version, siehe oben erst nach emerge -e passiert) sollte das egal sein, oder?

----------

## Diskus

Hallo ihr Zwei,

also bei mir kompiliert er jetzt fröhlich (329) world-Pakete neu und das ohne 4a und 4b. ,also ohne env-update.

habe auch nach der deinstallation vom 3.3.6 meine CFLAGS auf march=pentium-m gleich gewechselt und bis jetzt läuft es prima und auch schneller (bilde ich mir ein).

Ich hoffe das hält an und er zieht problemlos durch bis zum Schluß.

Diskus

----------

## SinoTech

 *amne wrote:*   

>  *SinoTech wrote:*   Ach ja, dann empfehl ich aber aus 4. das hier zu machen:
> 
> ```
> 
> 4a. emerge "libstdc++-v3" 
> ...

 

Jo, hatte bei mir, als ich mein update machte, auch kein "env-update" gemacht. Nur hab ich schon ein paar mal im Forum Fehlermeldungen bzgl. "libstdc++.*" gelesen, und dachte mir das ein "env-update" evtl. nicht verkehrt wäre. Solange der alte gcc noch installiert ist sollte es aber so oder so keine Probleme geben, nur ich würde den alten gcc vor dem "emerge -e" entfernen, schon alleine deswegen weil man so auch gleich neue CFLAGS setzen kann die nur vom neuen gcc unterstützt werden.

Mfg

Sino

----------

## amne

 *SinoTech wrote:*   

> Solange der alte gcc noch installiert ist sollte es aber so oder so keine Probleme geben, nur ich würde den alten gcc vor dem "emerge -e" entfernen, schon alleine deswegen weil man so auch gleich neue CFLAGS setzen kann die nur vom neuen gcc unterstützt werden.
> 
> 

 

Dann macht es vermutlich durchaus Sinn, die Anleitung ist was solche Sachen wie CFLAGS ändern angeht eher zurückhaltend gehalten, da eh schon so genug schief gehen kann und das Upgrade alle x86 User betrifft.

Wenn man weiss was man tut kann man durchaus ein wenig abweichen. Ich habe beim Testen z.b. nur emerge -e system gemacht und dann revdep-rebuild.  :Wink: 

----------

## SinoTech

 *amne wrote:*   

> 
> 
> [...]
> 
> Dann macht es vermutlich durchaus Sinn, die Anleitung ist was solche Sachen wie CFLAGS ändern angeht eher zurückhaltend gehalten, da eh schon so genug schief gehen kann und das Upgrade alle x86 User betrifft.
> ...

 

Stimmt, wird mit Sicherheit auch noch der eine oder andere kommen der damit Probleme hat.

 *amne wrote:*   

> 
> 
> [...]
> 
> Wenn man weiss was man tut kann man durchaus ein wenig abweichen. Ich habe beim Testen z.b. nur emerge -e system gemacht und dann revdep-rebuild. 

 

 :Wink:  Also kurz und schmerzlos  :Wink: 

Mfg

Sino

----------

## STiGMaTa_ch

Ich habe hier auch ein kleines Problem beim kompilieren von metalog.

Habe mir dieses Weekend die Zeit genommen, auf einem meiner Server ein SELinux (Hardened Gentoo) from Scratch zu installieren. Da ich mit einem Stage 1 angefangen habe, ist dort also das aktuellste gcc 3.4.4 drauf und alle Pakete wurden auch damit kompiliert.

Nun wollte ich wie in der Anleitung beschrieben metalog emergen und erhalte folgende Fehlermeldung:

```
i686-pc-linux-gnu-gcc -c -march=pentium4 -O2 -pipe -fomit-frame-pointer -fPIC -I. -I. -DSUPPORT_UTF8  -DIS_UNIX ./pcregrep.c

 i686-pc-linux-gnu-g++ -c -march=pentium4 -O2 -pipe -fomit-frame-pointer -fPIC -I. -I. -DSUPPORT_UTF8 -DPOSIX_MALLOC_THRESHOLD=10 ./pcrecpp.cc  -fPIC -DPIC -o .libs/pcrecpp.o

 i686-pc-linux-gnu-g++ -c -march=pentium4 -O2 -pipe -fomit-frame-pointer -fPIC -I. -I. -DSUPPORT_UTF8 -DPOSIX_MALLOC_THRESHOLD=10 ./pcre_scanner.cc  -fPIC -DPIC -o .libs/pcre_scanner.o

 i686-pc-linux-gnu-g++ -c -march=pentium4 -O2 -pipe -fomit-frame-pointer -fPIC -I. -I. -DSUPPORT_UTF8 -DPOSIX_MALLOC_THRESHOLD=10 ./pcre_scanner.cc -o pcre_scanner.o >/dev/null 2>&1

 i686-pc-linux-gnu-g++ -c -march=pentium4 -O2 -pipe -fomit-frame-pointer -fPIC -I. -I. -DSUPPORT_UTF8 -DPOSIX_MALLOC_THRESHOLD=10 ./pcrecpp.cc -o pcrecpp.o >/dev/null 2>&1

i686-pc-linux-gnu-g++ -c -march=pentium4 -O2 -pipe -fomit-frame-pointer -fPIC -I. -I. -DSUPPORT_UTF8   ./pcrecpp_unittest.cc

 i686-pc-linux-gnu-g++ -c -march=pentium4 -O2 -pipe -fomit-frame-pointer -fPIC -I. -I. -DSUPPORT_UTF8 -DPOSIX_MALLOC_THRESHOLD=10 ./pcre_stringpiece.cc  -fPIC -DPIC -o .libs/pcre_stringpiece.o

In file included from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/bits/locale_facets.h:1533,

                 from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/bits/basic_ios.h:44,

                 from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/ios:51,

                 from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/ostream:45,

                 from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/iostream:45,

                 from ./pcre_stringpiece.cc:33:

/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/bits/codecvt.h:475:44: bits/codecvt_specializations.h: No such file or directory

make: *** [pcre_stringpiece.o] Error 1

make: *** Waiting for unfinished jobs....

!!! ERROR: dev-libs/libpcre-6.3 failed.

!!! Function src_compile, Line 38, Exitcode 2

!!! (no error message)

!!! If you need support, post the topmost build error, NOT this status message.

```

Und noch emerge --info, falls die Info was hilft.

```
Portage 2.0.51.22-r3 (hardened/x86/2.6, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14 i686)

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

System uname: 2.6.14 i686 Intel(R) Celeron(R) CPU 2.40GHz

Gentoo Base System version 1.6.13

dev-lang/python:     2.3.5, 2.4.2

sys-apps/sandbox:    1.2.12

sys-devel/autoconf:  2.13, 2.59-r6

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

sys-devel/binutils:  2.16.1

sys-devel/libtool:   1.5.20

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

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

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"

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

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks sandbox sfperms strict"

GENTOO_MIRRORS="http://mirror.switch.ch/ftp/mirror/gentoo http://gentoo.mirror.solnet.ch"

MAKEOPTS="-j2"

PKGDIR="/usr/portage//packages/x86/"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage/"

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

USE="berkdb bzip2 crypt dlloader expat hardened ncurses nls pam perl pic python readline ssl tcpd userlocales x86 zlib userland_GNU kernel_linux elibc_glibc"

Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
```

Da dies mein erster Versuch ist, ein Hardened Gentoo zu installiern und dummerweise diese Umstellung grad reingeplatzt ist, bin ich nun etwas ratlos ob das Problem mit der gcc in Verbindung zu bringen ist, mit hardened gentoo im allgemeinen oder mit was völlig anderem.

Falls mir jemand nen Tipp hätte, wäre ich dankbar...

Lieber Gruss

STiMGaTa

----------

## SinoTech

 *STiGMaTa_ch wrote:*   

> 
> 
> [...]
> 
> /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/bits/codecvt.h:475:44: bits/codecvt_specializations.h: No such file or directory
> ...

 

Also laut Portage file list liegt die gesucht Datei unter

```

/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/i686-pc-linux-gnu/bits/codecvt_specializations.h

```

Da dies aber auch schon bei früheren gcc Versionen so war (siehe Link) sollte das kein Problem des neuen gcc sein.

Mfg

Sino

EDIT:

Bei mir hat es funktioniert ... evtl. solltest du dafür einen neuen Thread starten.

----------

## SinoTech

@ STiGMaTa_ch

Ist es möglich das du auf deinem erwähnten Server UTF8 (unicode) benutzt?

Mfg

Sino

----------

## STiGMaTa_ch

 *SinoTech wrote:*   

> @ STiGMaTa_ch
> 
> Ist es möglich das du auf deinem erwähnten Server UTF8 (unicode) benutzt?

 

Nicht bewusst:

/etc/rc.conf

```
UNICODE="no"
```

/etc/conf.d/consolefont

```
CONSOLEFONT="default8x16"
```

/etc/conf.d/keymaps

```
KEYMAP="us"

SET_WINDOWKEYS="no"

EXTENDED_KEYMAPS=""

DUMPKEYS_CHARSET=""
```

 *SinoTech wrote:*   

> Bei mir hat es funktioniert ...

 

Hast du denn versucht metalog zu emergen oder dieses libpcre? Den ich habe grade gemerkt, dass nicht metalog das Problem ist sondern seine Abhängigkeit libpcre.

Danke für die Unterstützung SinoTech.

Lieber Gruss

STiGMaTa

----------

## SinoTech

1. Habe die Abhängigkeit versucht zu emergen (Also das Paket das bei dir fehl schlug).

2. Habe glaub Problem gefunden. Problem liegt in einem der Header files des gcc und zwar in

```

/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/bits/codecvt.h

```

Da stehen ganz unten folgende Zeilen:

```

#ifdef _GLIBCXX_USE_WCHAR_T

  #include <bits/codecvt_specializations.h>

#endif

```

Heißt falls unicode benutzt wird (also wenn die glibc mit unicode kompiliert wurde), dann noch "bits/codecvt_specializations.h" includieren.

Das include Verzeichniss des gcc (Also das Verzeichniss in dem der gcc nach den header files sucht) ist auf folgendes Verzeichniss eingestellt:

```

/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3

```

(Siehst in der Ausgabe von "gcc -v")

Als Resultat probiert der gcc also diese Datei zu includieren:

 *Quote:*   

> 
> 
> /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/bits/codecvt_specializations.h
> 
> 

 

Aber die Datei liegt hier:

 *Quote:*   

> 
> 
> /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/i686-pc-linux-gnu/bits/codecvt_specializations.h
> 
> 

 

Und somit kann sie nicht gefunden werden. Ist aber auch beim alten "gcc-3.3.X" so ... keine Ahnung wieso. Also änder mal in dieser Datei:

```

/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/bits/codecvt.h

```

Die Zeilen (ganz unten) von

 *Quote:*   

> 
> 
> #ifdef _GLIBCXX_USE_WCHAR_T
> 
>   #include <bits/codecvt_specializations.h>
> ...

 

zu

 *Quote:*   

> 
> 
> #ifdef _GLIBCXX_USE_WCHAR_T
> 
>      #include <i686-pc-linux-gnu/bits/codecvt_specializations.h>
> ...

 

Danach sollte es funktionieren. Falls ich mich irre, kannst du die Änderung ja wieder rückgängig machen (Ist ja nur eine Zeile).

Mfg

Sino

----------

## STiGMaTa_ch

 *SinoTech wrote:*   

>  Also änder mal in dieser Datei:
> 
> ```
> 
> /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/bits/codecvt.h
> ...

 

Hat leider nichts gebracht  :Sad:  Die Fehlermeldung bleibt bis auf den Pfad gleich.

 *Quote:*   

> /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/bits/codecvt.h:475:62: i686-pc-linux-gnu/bits/codecvt_specializations.h: No such file or directory

 

Will heissen, auf meinem System gibt es gar kein codecvt_specializations.h

```
(none) linux # ls /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3/i686-pc-linux-gnu/bits/

atomic_word.h   c++config.h  ctype_base.h       gthr-default.h  gthr.h              stdc++.h.gch

basic_file.h    c++io.h      ctype_inline.h     gthr-posix.h    messages_members.h  time_members.h

c++allocator.h  c++locale.h  ctype_noninline.h  gthr-single.h   os_defines.h
```

Und weil du jetzt immer von Unicode gesprochen hast, habe ich mal den ganzen Output von configure angeschaut. Und siehe da, libpcre wird folgendermassen konfiguriert:

 *Quote:*   

> ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --build=i686-pc-linux-gnu --enable-utf8

 

Und im Ebuild findet man dann auch:

```
src_compile() {

        # How about the following flags?

        # --enable-unicode-properties  enable Unicode properties support

        # --disable-stack-for-recursion  disable use of stack recursion when matching

        econf --enable-utf8 || die
```

Soll ich mal das Ebuild frisieren und die Zeile auskommentieren oder wäre es gescheiter nach dem Grund des Nichtvorhanden seins von codecvt_specializations.h zu suchen?

Lieber Gruss

STiGMaTa

----------

## mrsteven

*grr* mein Rechner hat den halben Tag lang an "emerge -e system" rumgemacht, nur damit ich feststellen kann, dass ich das gleiche Problem wie Diskus habe. Das "emerge -e system" spare ich mir jetzt und gehe nach SinoTechs Methode vor.

Das hätte beim Testen doch eigentlich auffallen müssen, der gcc-3.4 war schließlich lange genug ~x86...  :Rolling Eyes: 

----------

## SinoTech

 *STiGMaTa_ch wrote:*   

> 
> 
> [...]
> 
> Und im Ebuild findet man dann auch:
> ...

 

Ok, also ich habe grad bemerkt das er bei mir auch an diese Stelle kommt an der versucht diese fehlende Datei einzubinden. Bei mir geht es aber und zwar mit beiden Einträgen:

#include <bits/codecvt_specializations.h>

bzw.

#include <i686-pc-linux-gnu/bits/codecvt_specializations.h>

Anscheinend durchsucht er das erste Verzeichniss per default und nur das zweite Verzeichniss muss extra angegeben werden.

Das Problem bei dir ist also einfach das dir einige Dateien fehlen. Hast du den gcc-3.4.4 neu ge-emerged?

Ach ja, das ebuild ändern würde zwar möglicherweise den Fehler kurz fristig beheben, nur über kurz oder lang hättest du doch wieder Probleme.

Also probier mal den gcc-3.4.4 neu zu emergen und schau ob dann die Dateien da sind.

Mfg

Sino

----------

## Tranalogic1987

Hallo,

öhm ganz blöde Frage. Hab den gcc-3.3.x gelöscht bevor ich die libstdc++-v3 installiert habe. Was tun? Es fehlt bei jedem Programm die libstdc++.so.5, nautilus nervt mich die ganze zeit mit einem absturz und emerge (python) braucht auch die lib. Könnt ihr mir vielleicht sagen wie die libstdc++ bz2 Datei heisst, sonst kompilier ichs mir selber. Wer sich jetzt fragt, warum hab ich nicht das nach dem HowTo gemacht. Naja emerge hat mir keine auffällige Meldung gegeben das, wenn ich gcc installiere und nach der installation nach dem HowTo nicht vorgehe, das es mir mein System sprengt. (is ja nur Nebensache)

Wer mir bitte Helfen kann, dem bin ich dankbar. Neuinstallieren will ich das System nicht, da installier ich mir eher FreeBSD

----------

## SinoTech

Schaust du mal hier: HOWTO_Recover_from_"emerge_--unmerge_gcc"

Mfg

Sino

----------

## ruth

hai  :Wink: 

jetzt hats mich auch erwischt...

```

SHLIB_INSTALL='$(SHELL) $(srcdir)/mkinstalldirs $(DESTDIR)$(slibdir)@shlib_slibdir_qual@; /bin/install -c -m 644 @shlib_dir@@shlib_so_name@.so.1 $(DESTDIR)$(slibdir)@shlib_slibdir_qual@/@shlib_so_name@.so.1; rm -f $(DESTDIR)$(slibdir)@shlib_slibdir_qual@/@shlib_base_name@.so; ln -s @shlib_so_name@.so.1 $(DESTDIR)$(slibdir)@shlib_slibdir_qual@/@shlib_base_name@.so' \

SHLIB_EXT='.so' \

SHLIB_MULTILIB='' \

SHLIB_MKMAP='/var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/gcc/mkmap-symver.awk' \

SHLIB_MKMAP_OPTS='' \

SHLIB_MAPFILES='/var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/gcc/libgcc-std.ver /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/gcc/config/libgcc-glibc.ver' \

SHLIB_NM_FLAGS='-pg' \

MULTILIB_OSDIRNAMES='' \

mkinstalldirs='/bin/sh /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/gcc/mkinstalldirs' \

  /bin/sh mklibgcc > tmp-libgcc.mk

mv tmp-libgcc.mk libgcc.mk

TARGET_CPU_DEFAULT="" \

HEADERS="ansidecl.h" DEFINES="" \

/bin/sh /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/gcc/mkconfig.sh tconfig.h

./xgcc -B./ -B/usr/i686-pc-linux-gnu/bin/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -L/var/tmp/portage/gcc-3.4.4-r1/work/build/gcc/../ld -fno-stack-protector-all -O2 -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I. -I. -I/var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/gcc -I/var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/gcc/. -I/var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/gcc/../include   -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \

   -c /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/gcc/crtstuff.c -DCRT_BEGIN \

  -o crtbegin.o

xgcc: spec failure: unrecognized spec option 'v'

xgcc: spec failure: unrecognized spec option 'v'

xgcc: spec failure: unrecognized spec option 'v'

xgcc: spec failure: unrecognized spec option 'p'

xgcc: spec failure: unrecognized spec option 'P'

make[2]: *** [crtbegin.o] Aborted

make[2]: Leaving directory `/var/tmp/portage/gcc-3.4.4-r1/work/build/gcc'

make[1]: *** [stage1_build] Error 2

make[1]: Leaving directory `/var/tmp/portage/gcc-3.4.4-r1/work/build/gcc'

make: *** [profiledbootstrap] Error 2

```

*grmbl*

was is das nu wieder???

ach ja:

```

[root@gate02](~/aide) # emerge --info

Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.3.6-hardenednopie, glibc-2.3.5-r2, 2.6.14.2 i686)

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

System uname: 2.6.14.2 i686 AMD Duron(tm) processor

Gentoo Base System version 1.6.13

dev-lang/python:     2.3.5-r2, 2.4.2

sys-apps/sandbox:    1.2.12

sys-devel/autoconf:  2.13, 2.59-r6

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

sys-devel/binutils:  2.16.1

sys-devel/libtool:   1.5.20

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=athlon-tbird -pipe -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"

CXXFLAGS="-O2 -march=athlon-tbird -pipe -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks sandbox sfperms strict"

GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/ ftp://gentoo.inode.at/source/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/"

PKGDIR="/usr/portage/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage"

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

USE="x86 acl apache2 apm arts avi berkdb bitmap-fonts bzip2 cdb crypt cups curl dcpd eds emboss encode expat foomaticdb fortran gdbm gif gmp gpm gstreamer gtk2 idn imap imlib jpeg libg++ libwww mad maildir mhash mikmod motif mp3 mpeg mysql ncurses no-htdocs nptl nptlonly ogg opengl oss pam pcre pdflib perl pic pie png python quicktime readline sasl sdl slang spell ssl tcpd tiff truetype truetype-fonts type1-fonts udev userlocales vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"

Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS

```

naja, mal sehen...  :Wink: 

ach ja:

```

[root@gate02](~/aide) # gcc-config -l

 [1] i686-pc-linux-gnu-3.3.6

 [2] i686-pc-linux-gnu-3.3.6-hardenednopie *

 [3] i686-pc-linux-gnu-3.3.6-hardenednopiessp

 [4] i686-pc-linux-gnu-3.3.6-hardenednossp

 [5] i686-pc-linux-gnu-3.3.6-vanilla

```

wird das zeugs eigentlich auch mal getestet? weil anscheinend gehts mit hardened flags nicht...  :Sad: 

gruss

ruth

----------

## buthus

 *SinoTech wrote:*   

> Also habe mal testweise wieder einen älteren gcc intstalliert, und bei mir switcht er nicht:
> 
> ```
> 
> * The current gcc config appears valid, so it will not be
> ...

 

hallo,

ich hab es auch erst so gemacht wie amne es beschrieben hat, aber leider hat mein rechner auch wieder auf die alte gcc geswitcht, daher mache ich es jetzt mal so wie SinoTech es beschreibt, hab allerdings eine frage dazu : reicht anschliessend das 

```
emerge -e world
```

oder sollte ich vorher noch 

```
emerge -e system
```

 ausführen?

----------

## SinoTech

Ein "emerge -e world" reicht.

Mfg

Sino

----------

## STiGMaTa_ch

 *SinoTech wrote:*   

> Das Problem bei dir ist also einfach das dir einige Dateien fehlen. Hast du den gcc-3.4.4 neu ge-emerged?[...]
> 
> Also probier mal den gcc-3.4.4 neu zu emergen und schau ob dann die Dateien da sind.

 

Nun sieh einer an... Einen gcc emerge später und es funktioniert  :Very Happy:  Super!

Nur kapiere ich nicht ganz warum... Hab doch mit einer Stage 1 angefangen, das bedeutet beim bootstrappen wurde schon der gcc 3.4.4 gemergegt, dann nochmals beim Stage 2 emerge --emptytree world... Naja, egal. Das hat geholfen!

Dank Sino für die Super Unterstützung!

Lieber Gruss

STiGMaTa

----------

## SinoTech

Tja, ich weiß warum ich immer Stage 3 mache:

- weniger arbeit und ...

- weniger Probleme  :Wink: 

Mfg

Sino

----------

## amne

Das automatische Umschalten wurde inzwischen als Bug identifiziert und gefixt. Sobald die Änderungen live sind muss man wirklich von Hand auf 3.4.4 umschalten.

----------

## tango

Bei mir hat er es zwar versucht, aber bei einer Fehlermeldung aufgegeben..

Bin gerade dabei mit revdep-rebuild alles zu scannen und neu zu bauen..

Bei gcc-4.x gönne ich meinem System dann ein emerge -e world   :Wink: 

Aber leider habe ich nicht allzu viel Zeit  :Sad: 

tango

----------

## pablo_supertux

Ich hab gestern abend emerge -e system laufen lassen und auf meinem P3 lief die ganze Nacht sauber durch (bis quasi 10 Uhr morgens), weil es 114 Paketen waren.

Nun wollte ich jetzt weiter mit emerge -e world machen, aber das hat mich noch mehr erschreckt, 479 Pakete. Nachdem ich mir eine Liste gemacht habe, wo alle Pakete drin sind, die in word und system vorkamen und diese aus der der Liste entfern hatte, hat sich meine Liste zu 360 rediziert, toll oder?   :Crying or Very sad:  aber es ist trotzdem verdammt viel, dazu braucht mein Rechner bestimmt 2 volle Tage oder so.

Deswegen, wie wichtig ist es emerge -e world auszuführen? Welche Pakete müssen neu übersetzt werden, so dass beim Neustart alles sauber läuft?

----------

## EdtheRat

 *pablo_supertux wrote:*   

> Ich hab gestern abend emerge -e system laufen lassen und auf meinem P3 lief die ganze Nacht sauber durch (bis quasi 10 Uhr morgens), weil es 114 Paketen waren.
> 
> Nun wollte ich jetzt weiter mit emerge -e world machen, aber das hat mich noch mehr erschreckt, 479 Pakete. Nachdem ich mir eine Liste gemacht habe, wo alle Pakete drin sind, die in word und system vorkamen und diese aus der der Liste entfern hatte, hat sich meine Liste zu 360 rediziert, toll oder?   aber es ist trotzdem verdammt viel, dazu braucht mein Rechner bestimmt 2 volle Tage oder so.
> 
> Deswegen, wie wichtig ist es emerge -e world auszuführen? Welche Pakete müssen neu übersetzt werden, so dass beim Neustart alles sauber läuft?

 

423....Pakete bei mir? Ich glaube auch schon fast, ne Neuinstallation wäre schneller mit Stage3 ........  :Shocked: 

----------

## Diskus

Hallo,

bei mir waren es auch 329 Pakete,wären die Cpu´s halt was anderes geworden.-ist doch egal aber dafür haben wir ein neues und blitzsauberes System.

hoffentlich stellen wir jetzt nicht bald auf gcc4..... um.

Diskus

----------

## tango

Mit der revdep-rebuild Methode sind es bloß 75, das dauert schon lange genug   :Wink: 

Aber gerade deshalb nutzen wir doch Gentoo, oder ?

tango

----------

## klemi

Hallo,

ich habe eine Frage zu den CFLAGS beim gcc 3.4.4. Was genau hat sich da geändert?

Ich habe ienen 3GHz AMD Athlon XP.

Meine make.conf sieht so aus:

 *Quote:*   

> ACCEPT_KEYWORDS="x86"
> 
> CFLAGS="-O2 -march=athlon-xp -pipe"
> 
> CHOST="i686-pc-linux-gnu"
> ...

 

Müßte/sollte da was geändert werden???

Danke für Eure Aufklärung!

Gruß

Klemi

----------

## amne

 *klemi wrote:*   

> 
> 
> Müßte/sollte da was geändert werden???
> 
> 

 

Nein, für Athlon-XP ist nix neues gekommen und -O2 -march=athlon-xp -pipe sind schon sehr schöne Optimierungen die auch keine Probleme bereiten.  :Very Happy: 

----------

## klemi

Danke!

Gruß von der Donau

----------

## smg

Hallo,

kann ich auch erstmal den neuen GCC emergen, aber nicht verwenden?

Das ist doch auch okay, oder?

Cheers.

----------

## amne

 *hagbard_ wrote:*   

> Hallo,
> 
> kann ich auch erstmal den neuen GCC emergen, aber nicht verwenden?
> 
> Das ist doch auch okay, oder?

 

Klar, so lange du nicht mit gcc-config umstellst ändert sich nichts.

----------

## smg

 *amne wrote:*   

>  *hagbard_ wrote:*   Hallo,
> 
> kann ich auch erstmal den neuen GCC emergen, aber nicht verwenden?
> 
> Das ist doch auch okay, oder? 
> ...

 

Okay, das ist sehr gut. Habe nämlich erst ab Dienstag Zeit einen revdep-rebuild laufen zu lassen.

Cheers.

----------

## klemi

Was passiert eigentlich mit den Binaries, wie z.B. OOffice2-bin? Die bleiben ja!Kann es im System da zu Problemen kommen?

Danke!

Gruß

Klemi

----------

## SinoTech

 *klemi wrote:*   

> Was passiert eigentlich mit den Binaries, wie z.B. OOffice2-bin? Die bleiben ja!Kann es im System da zu Problemen kommen?
> 
> Danke!
> 
> Gruß
> ...

 

Nein, diese sind gegen die Bibliotheken des gcc-3.3.X gelinkt, und als Ersatz für dessen libraries installierst du ja das Paket "libstdc++-v3". Die benötigten Bibliotheken bleiben also im System (Nur eben durch ein anderes Paket), nur der zugehörige Compiler fliegt raus.

Mfg

Sino

----------

## TheSmallOne

 *SinoTech wrote:*   

> Ein "emerge -e world" reicht.

 

Dazu mal eine Frage:

Alle Pakete aus 'system' stecken ja auch im 'world'.

Welchen Vorteil hat es denn eigentlich erst ein "emerge -e system" auszuführen, wenn dannach ein "emerge -e world" kommt und alles, was zuvor kompiliert wurde gleich nochmal kompiliert wird?

Der große Nachteil ist offensichtlich alles zweimal zu kompilieren, was Zeit in Anspruch nimmt, aber worin liegt denn der Vorteil?

----------

## Diskus

Hallo,

also meine Bilanz:

nach 2 Tagen intensivsten compilieren und 2 kleinen Abbrüchen ist der Umstieg auf 3.4.4 jetzt abgeschlossen und alles funktioniert vollkommen reibungslos-auch das update auf kde-3.5.0 welches gleich mitinstalliert wurde geht prima.

Diskus

----------

## SinoTech

 *TheSmallOne wrote:*   

>  *SinoTech wrote:*   Ein "emerge -e world" reicht. 
> 
> Dazu mal eine Frage:
> 
> Alle Pakete aus 'system' stecken ja auch im 'world'.
> ...

 

In "system" stecken alle Programme und Bibliotheken die das System braucht um zu laufen (gcc, glibc, ... und alles was durch gesetzte USE-Flags dazu kommt). Wichtig ist nun das die Toolchain (Also wirklich die wichtigsten Komponenten) mit dem selben Compiler erzeugt wurden. Dazu reicht es wenn du folgendes machst:

1. Den gcc installieren (Der wird hierbei gleich zweimal gebaut. Einmal mit dem aktuellen gcc, und ein zweites mal von sich selbst)

2. binutils und glibc emergen. Dadurch werden sie zwar vom neuen gcc compiliert, der nutzt aber noch die alten Bibliotheken. Also machst du als nächstes

3. "emerge glibc binutils gcc". Also baust diese drei Pakete nochmals neu. Damit hast du jetzt eine Toolchain die in sich konsistent ist.

(Anstatt die Pakete einzeln zu emergen, kannst du natürlich auch "emerge -e system" machen, was dann aber mit Sicherheit etwas mehr Pakete mitbringt)

Mit der neuen Toolchain kannst du dann den Rest von deinem System neu bauen, so das alle programme die neuen Bibliotheken benutzen. Die "libstdc++-v3" brauchst du nur für Binärpakete, also Programme die du nicht neu bauen kannst, da diese weiterhin die alten Bibliotheken benötigen.

Mfg

Sino

----------

## TheSmallOne

Also müssen letztlich eigentlich nur diese 3 Pakete je zweimal kompiliert werden?

Hm, dafür dann ein komplettes "emerge -e system", welches (bei mir) 112 Pakete kompiliert auszuführen lohnt irgendwie nicht wirklich.

Naja, jetzt stecke ich schon mitten im "emerge -e system", also bleibt mir wohl nicht viel anderes übrig, als alles zweimal zu kompilieren.  :Smile: 

Irgendwie wäre doch eine Art "emerge toolchain" für diesen Zweck ganz praktisch.

----------

## SinoTech

 *TheSmallOne wrote:*   

> Also müssen letztlich eigentlich nur diese 3 Pakete je zweimal kompiliert werden?
> 
> Hm, dafür dann ein komplettes "emerge -e system", welches (bei mir) 112 Pakete kompiliert auszuführen lohnt irgendwie nicht wirklich.
> 
> Naja, jetzt stecke ich schon mitten im "emerge -e system", also bleibt mir wohl nicht viel anderes übrig, als alles zweimal zu kompilieren. 
> ...

 

Sehe ich genauso, wobei ich da aber auch kein Guru bin. Kann nur das wiedergeben was ich schon öfters gelesen habe und was mir logisch erscheint. Zumindest hatte ich bisher noch keine Probleme damit (Habe schon upgrade von gcc-3.3.X -> 3.4.X und gcc-3.4.X -> gcc-4.0.X hinter mir  :Smile:  ).

Wenn ich was falsch erklärt habe möge mich bitte jemand verbessern.

Mfg

Sino

----------

## buthus

nach 547 paketen bzw. 51 stunden dauerrödeln, klappt bei mir jetzt auch wieder alles. also herzlichen dank an amne und Sino für die guten anleitungen!

mein "server" wird wohl noch so 2 tage brauchen, sind zwar nur 463 pakete, aber auch nur 500 MHz   :Very Happy: 

----------

## klemi

HAllo jetzt hat es mich erwischt beim 300. Packet war Ende.

 *Quote:*   

> >>> emerge (300 of 485) app-text/docbook-xml-dtd-4.1.2-r5 to /
> 
> >>> Resuming download...
> 
> >>> Downloading ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo/distfiles/docbkx412.zip
> ...

 

Kann ich den Prozess irgendwie fortfahren, oder muß ich alles noch mal von vorn?

Danke!

Gruß

Klemi

----------

## SinoTech

Probier mal das herunter geladene file zu löschen

```

$ rm /usr/portage/distfiles/docbkx412.zip

```

und dann einfahre mittels "emerge --resume" dein world update fort. Falls das nicht hilft, überspringst du das Paket am besten erstmal:

```

$ emerge --resume --skipfirst

```

Ein "emerge --sync" könnte da auch helfen, nur kannst du danach nicht mehr mit "--resume" fortfahren  :Sad: .

Mfg

Sino

----------

## klemi

Hallo SiniTech,

ich war etwas voreilig und habe mit emerge -e system nichts bewirkt, da hier wieder ggc und binutils usw. compiliert wurden.

Nach einem emerge --sync, dann

Ein emerge --sync ergibt:

>>> Updating Portage cache:  100%

 *Quote:*   

>  * IMPORTANT: 18 config files in /etc need updating.
> 
>  * IMPORTANT: 1 config files in /usr/lib/X11/xkb need updating.
> 
>  * Type emerge --help config to learn how to update config files.

 

Zuerst etc-update durchführen - oder besser, wenn das System komplett fertig ist.

danach 

emerge -avuD --tree world eingeben - oder wie?

das ergibt aber

These are the packages that I would merge, in reverse order:

 *Quote:*   

> Calculating world dependencies ...done!
> 
> [ebuild     U ] media-video/nvidia-glx-1.0.8174 [1.0.7676-r2] -dlloader 11,717 kB
> 
> [ebuild     U ]  media-video/nvidia-kernel-1.0.8174 [1.0.7676-r1] 0 kB
> ...

 

nur neue Paket updaten!

Gruß

Klemi

----------

## SinoTech

 *klemi wrote:*   

> 
> 
> Hallo SiniTech,
> 
> [...]
> ...

 

SinoTech bitte!  :Very Happy: 

 *klemi wrote:*   

> 
> 
> [...]
> 
> Nach einem emerge --sync, dann
> ...

 

Eigentlich ist es egal wann du dieses update durchführst.

 *klemi wrote:*   

> 
> 
> [...]
> 
> danach 
> ...

 

Naja, eigentlich wollten wir doch ein "emerge -e world" machen, um das komplette System neu zu kompilieren. Gereicht hätte da jetzt auch ein "emerge --resume", da du mit world schon begonnen hattest. Nur da du zwischenzeitlich mit emerge rumgespielt hast ("emerge --sync", ...), wird er nicht mehr resumen können. Heißt also entweder du beginnst die Kompilierorgie wieder von vorne ("emerge -e world"), oder, da du schon einen Großteil von deinem System neu kompiliert hast, lässt du den Rest einfach einmal von "revdep-rebuild" checken (Siehe Anleitung von "amne").

Mfg

Sino

----------

## klemi

Danke, vielen Dank, SinoTech!

Ich habe mich für ein einen Neubeginn emerge --e world entschieden.

Übung macht den Meister .... oder so!

Gruß

Klemi

----------

## schmutzfinger

Ich habe mir jetzt nicht jeden Post bis aufs Detail durchgelesen aber imho wurde noch garnicht erwähnt das man seinen kernel auch neu bauen sollte. Sonst kommt nämlich sowas hier raus

```

 nvidia: version magic '2.6.14.2 preempt K7 gcc-3.4' should be '2.6.14.2 preempt K7 gcc-3.3'

```

was dann wohl auch bei lirc, vmware und allen anderen Nachbau- modulen passiert.

Mein X ging nach nem nvidia Update nichtmehr und das nur weil automatisch auf gcc3.4 gewechselt wurde.

Dann habe ich noch ne grundlegende Frage. Ich würde eh nur revdep-rebuild machen, aber ehrlichgesagt ist mir das schon zuviel. Sorgt libstdc++-v3 nicht dafür das meine alten Binaries noch weiterlaufen? Früher oder später werden die Programme eh neu gebaut, da würde ich mir nur ungerne 24h auf einmal antun.

Mein Vorschlag wäre:

```

# emerge -uav gcc

# gcc-config i686-pc-linux-gnu-3.4.4

# source /etc/profile

# emerge sys-libs/libstdc++-v3

```

kernel neu bauen

```

# emerge nvidia-kernel lirc -auv

# vmware-config.pl

```

Reicht das oder muss man wirklich alles neu bauen?

----------

## SinoTech

 *schmutzfinger wrote:*   

> 
> 
> [...]
> 
> Mein Vorschlag wäre:
> ...

 

1. Erstmal danke für den hinweis mit dem kernel, das hat wohl jeder hier vergessen (Mich eingeschlossen  :Sad: ). Habe es mal schnell in meinem Post auf der ersten Seite eingefügt.

2. Zumindest die Toolchain solltest du, nach dem du auf den neuen gcc gewechselt hast, neu kompilieren

```

$ emerge binutils glibc && emerge binutils glibc gcc

```

Ein komplettes "emerge -e world" ist evtl. nicht nötig, aber zumindest ein revdep-rebuild sollte ein muss sein, um die konsitenz der programme zu den Libraries sicher zustellen. Ausserdem sollte man hier im Forum immer den sichersten Weg erklären und nicht den schnellsten.

Mfg

Sino

EDIT:

1. Amne hatte anscheinend schon den Hinweis mit dem kernel in seinem ursprünglichen Post:

 *amne wrote:*   

> 
> 
> # Kernelmodule (z.B. app-emulation/qemu-softmmu), die mit dem neuen gcc 3.4.4 übersetzt wurden funktionieren nicht mit dem alten Kernel. Lösung: Auch diesen mit 3.4.4 neu übersetzen.
> 
> 

 

(Evtl. auch erst nachträglich eingefügt)

2. Hat amne in seinem Post noch diese schöne fehlermeldung stehen:

 *amne wrote:*   

> 
> 
> # Dieser Fehler
> 
> libtool: link: `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la' is not a valid libtool archive
> ...

 

Die "libstdc++.la" ist anscheinend nicht im Paket "libstdc++-v3" enthalten. Ich weiß zwar nicht wann es zu diesem Fehler kommt, aber ich denke mal es ist wichtig das die programme gegen die aktuelle Version gelinkt werden, da die alte nach dem unmergen des alten gcc nicht mehr existiert. Insofern würde ich schon sagen das ein "emerge -e world" nicht verkehrt ist.

Man verbessere mich wenn ich falsch liege  :Smile: 

----------

## amne

 *SinoTech wrote:*   

> 
> 
> Ein komplettes "emerge -e world" ist evtl. nicht nötig, aber zumindest ein revdep-rebuild sollte ein muss sein, um die konsitenz der programme zu den Libraries sicher zustellen.
> 
> 

 

Auf jeden Fall. Ich bin mir nicht einmal 100% sicher ob die Programme mit der libstdc++.so.5 aus libstdc++-v3 laufen - ich dachte eigentlich das funktioniert nur mit -bin Paketen (openoffice-bin). Selbst wenn - man sollte auf jeden Fall kein Mischsystem verwenden, ein Mischsystem führt zu potentiell ekeligen Problemen, siehe Bug 64615 und Bug 61146.

 *SinoTech wrote:*   

> 
> 
> Ausserdem sollte man hier im Forum immer den sichersten Weg erklären und nicht den schnellsten.

 

Richtig. Selbst wenn es möglich wäre, Programme mit libstdc++-v3 weiter zu verwenden, sicher ist es nicht.  :Wink: 

 *SinoTech wrote:*   

> 
> 
> 1. Amne hatte anscheinend schon den Hinweis mit dem kernel in seinem ursprünglichen Post:
> 
>  *amne wrote:*   
> ...

 

Nein, das war schon immer drin.  :Wink: 

 *SinoTech wrote:*   

> 
> 
> 2. Hat amne in seinem Post noch diese schöne fehlermeldung stehen:
> 
>  *amne wrote:*   
> ...

 

Dieser Fehler tritt beim übersetzen von Programmen auf, wenn die Libtoolarchive nach dem Gcc-Update nicht auf die neueste Version gebracht wurden. Normalerweise ruft emerge gcc selbst fix_libtool_files.sh auf und kümmert sich darum, manchmal funktioniert es aber nicht. Im Gegensatz zu kaputten Libs tritt der Fehler aber eben nicht zur Laufzeit auf sondern nur beim Kompilieren.

----------

## schmutzfinger

Naja wo liegt denn der unterschied von nem binärpaket zu meinen unter 3.3 gebauten binaries? Und wenn ich mal so ein Problem wie in den beiden bugs bekomme dann merke ich das halt beim Bauen. Die Frage ist ja nur ob ich wirklich ernste Probleme zur Laufzeit bekommen kann? Also ständige kde crashes nur weil ich mit dem kde update noch auf 3.5 warte z.B.

----------

## amne

Das Problem mit Systemen, die von den empfohlenen Anweisungen abweichen ist immer, dass es zu obskuren Problemen kommen kann, die nur schwer auf ihre Ursache zurückzuführen sind. Deshalb sollten die User das im Guide empfohlene tun - abweichen sollte man nur dann, wenn man es wirklich besser weiss (was im Normalfall bedeutet: professioneller Entwickler, kann sämtliche Probleme selbst lösen, muss nicht im Forum nachfragen - die füllen dann auch keine Bugs aus oder benötigen Hilfe wenn sie auf so ein Problem stossen). Ansonsten würde ich dir wirklich raten, dem Guide einfach zu folgen.  :Wink: 

----------

## schmutzfinger

Naja ich bin mal so frech und anmassend. Sonst würde ich von nem gentoo Entwickler wenigstens diesen "Guide" im ewarn des ebuilds verlangen. Wenn ich Probleme damit bekomme melde ich micht. Also bis auf ein paar wenige Sachen habe ich noch nix neu gebaut, und für das nvidia bin ich kurz wieder zurück auf 3.3 gegangen weil ich nicht rebooten wollte.

----------

## amne

Aus toolchain.eclass

```

        if ! is_crosscompile && ! use multislot && [[ ${GCCMAJOR}.${GCCMINOR} == 3.4 ]] ; then

                echo

                einfo "You should make sure to rebuild all your C++ packages when"

                einfo "upgrading between different versions of gcc.  For example,"

                einfo "when moving to gcc-3.4 from gcc-3.3, emerge gentoolkit and run:"

                einfo "  # revdep-rebuild --library libstdc++.so.5"

                echo

                einfo "For more information on the steps to take when upgrading "

                einfo "from gcc-3.3 please refer to: "

                einfo "http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml"

                echo

        fi

```

 :Twisted Evil: 

Und es wurde kreuz und quer über alle Mailinglisten, den GWN, Foren und wasweissich gepostet.  :Wink: 

----------

## schmutzfinger

Ups. Ein Blick ins ebuild ist eben doch nicht genug. Ich gebe mich geschlagen und warte weiter auf portage 2.1. Ich werde auch bei den 24h -e world nicht daneben sitzen und wohl wieder ne Menge ewarn nicht lesen.

----------

## amne

Ich würde dir die revdep-rebuild Methode empfehlen, da musst du nur 12h danebensitzen und warten ob ein ewarn kommt.  :Wink: 

----------

## klemi

Noch eine Zusatzfrage:

Ich habe die "Portage-Beschleunigung" cdb installiert: https://forums.gentoo.org/viewtopic-t-261580-start-125.html.

Wenn  jetzt pyhton 2.4 neue compiert wird, passiert dannn was mit Portage? Da war mal was vor langer Zeit....Vorsicht bei phyton-updates!

Danke bzgl. Rückmeldungen

Gruß

Klemi

----------

## Ezekeel

Hallo - ich hoffe, dass die Frage nicht schonmal gestellt wurde... ist mir zumindest nirgendwo aufgefallen beim überfliegen des Threads.

Ist der Umstieg denn ratsam bzw. sollte man ihn vollführen mit einer stinknormalen amd xp cpu? Wenn ich gcc einfach maske gibt es dann für mich denn in naher Zukunft irgendwelche Probleme, da neue programme mit dem alten compiler (3.3.6) nicht mehr überstzt werden können? Bitte buht mich nicht aus... hab keinen Plan von dem ganzen. Eigentlich ist ja der Compiler nur dafür zuständig programmcode in maschinencode zu übersetzen und da meine maschine alt ist braucht sie ja keinen neuen code oder sehe ich das falsch?!

Will mir eh in den nächsten monaten ein dualcore system zusammenbauen und bis dahin habe ich keinen bock das ganze 2 mal zu übersetzen!!

----------

## amne

Gcc 3.3.x wird von Upstream-Seite her schon eher als veraltet angesehen, daher schaut es langfristig mit dem Support für 3.3.x schlecht aus. Wenn du das System aber sowieso bald ersetzen willst macht es vermutlich keinen Sinn das Update durchzuführen. Im schlimmsten Fall stösst du halt irgendwann auf ein Problem, das sich nur durch ein Upgrade > 3.4 lösen lässt, dann kannst du dir den Umstieg noch immer überlegen.

----------

## Vandroiy

Hallo,

ich habe das emerge -e system erfolgreich abgeschlossen und lasse seit heute morgen emerge -e world laufen (489 Pakete). Gerade hat er abgebrochen und brachte folgende Meldung

```
!!! Digest verification Failed:

!!!    /usr/portage/distfiles/docbkx412.zip

!!! Reason: Failed on MD5 verification
```

Meine Frage bezieht sich jetzt nicht auf den Fehler, sondern darauf, wie ich nicht nochmal alle 226 vorangehenden Pakete compilieren muss.

Vielen Dank!

Vandroiy.

----------

## buthus

emerge --resume

oder wenn der fehler wieder auftritt :

emerge --resume --skipfirst

----------

## Vandroiy

Vielen Dank, ich habe die defekte Datei gelöscht, jetzt geht es normal weiter.  :Smile: 

Vandroiy

----------

## stiwi

mal ne andere frage. wenn ich auf gcc3.4.4 update und dann emerge -e system und revde-rebuild mache. kann ich mir irgendwie anzeigen lassen welche eventuellen binärpackete noch auf die alte lib verlinken? sonst brauche ich die alte lib ja nicht extra installieren. danke

----------

## Rüpel

Toll. Super. Bei mir ist das Updaten der 422 Pakete mittendrin an tse3 gescheitert.

Da gibt es seit Mai   :Exclamation:   einen Patch im Bugzilla und weder 0.2.7 noch 0.3.0-r1 lassen sich mit arts-3.4.1-r2 und gcc-3.4.4 kompilieren.

Gibts da überhaupt noch einen Maintainer?   :Evil or Very Mad: 

...oder mach ich was falsch?

*edit*

Ha! Ich habs. Der Trick ist, dass nicht nur arts eine Abhängigkeit ist (wie das im ebuild von tse3 steht), sondern auch kdemultimedia-arts - wenn das vorher mit dem neuen Compiler gebaut wurde, dann läuft auch tse3 durch.

Ungepflegte ebuilds sind teilweise eine echte Last!   :Confused: 

----------

## Rüpel

Da ja ein emerge --resume bei mir nicht mehr in Frage kommt, ich aber natürlich nicht nochmal von vorne anfangen will, hab ich mir was überlegt. Ist ein Hack und bedarf einiger Arbeit, um das zu verallgemeinern, aber vielleicht hilft das ja jemandem.

Also Problem: emerge -e world ist irgendwann mittendrin abgebrochen, man fixt das Problem, installiert das problematische Paket erneut und will dann mit dem emerge -e world weitermachen. Geht nicht. Weil --resume sich immer nur aus das letzte emerge bezieht.  :Sad: 

Wer in der /etc/make.conf PORT_LOGDIR=/var/log/portage gesetzt hatte (und das Verzeichnis schonmal angelegt hatte) - vor dem ersten emerge -e world versteht sich - der weiß ja, was als letztes übersetzt wurde. Man muss nur die Infos aus dem logdir rauspopeln.

Ich hab mir alle von emerge -e world installierten Pakete in eine Datei geschrieben, zum Beispiel mit:

```
emerge -ep --nocolor world | cut -d ' ' -f8 | grep '/' > packages
```

Das will er also alles installieren.

Jetzt kommt Handarbeit. Ich suche mir im /var/log/portage Verzeichnis die Log-Datei des ersten Pakets meines ersten emerge -e world Aufrufs (der abgebrochene). Bei mir fängt es mit sys-devel/patch an. Die Logdatei heisst in meinem Fall: 2879-patch-2.5.9.log. Also alle Pakete, die danach installiert wurden, brauch ich nicht nochmal übersetzen. Mit diesem Wissen bearbeite ich das folgende Shellskript:

```
#!/bin/sh

for i in $(cat packages); do

  p=$(echo $i | cut -d '/' -f2)

  f=$(find /var/log/portage/ -newer /var/log/portage/2879-patch-2.5.9.log | grep $p)

  if [ -z "$f" ]

  then

    emerge =$i || exit 1;

  fi

done
```

 Die Referenzdatei an der entsprechenden Stelle eintragen.

Nicht besonders toll, nicht irgendwie super aromatisch, aber es läuft. ^^

Gibt bestimmt tausend andere und bessere Ansätze, aber wenigstens muss ich meine ersten 120 Pakete (darunter so Kleinigkeiten wie gcc, glibc und qt) nicht nochmal installieren.   :Rolling Eyes: 

----------

## tuxian

Wann genau kann ich CFLAGS wie -march=pentium-m setzen (bei Methode 2)?

Schon vor "emerge -e world"?

Sonst hab ich ja vorerst keinen Nutzen und müsste dann nochmals ein "emerge -e world" machen!

----------

## SinoTech

 *tuxian wrote:*   

> Wann genau kann ich CFLAGS wie -march=pentium-m setzen (bei Methode 2)?
> 
> Schon vor "emerge -e world"?
> 
> Sonst hab ich ja vorerst keinen Nutzen und müsste dann nochmals ein "emerge -e world" machen!

 

Ersetze das "emerge -e system" durch

```

$ emerge glibc binutils && emerge gcc glibc binutils

```

Damit hast du eine konsitente Toolchain. Danach kannst du den alten gcc löschen

```

$ emerge -C =gcc-<version>

```

Und jetzt kannst du die neuen CFLAGS setzen und dein "emerge -e world" machen.

WICHTIG:

Mache kein "emerge -C gcc" (Also ohne Versionsnummer) da dabei auch der neue gcc gelöscht wird. Also schön die Versionsnummer dazu schreiben !!!

Mfg

Sino

----------

## tuxian

Okay danke für die schnelle Info!

----------

## AntonWert

 *amne wrote:*   

> Warnung: Bitte jetzt noch keine neuen, nur von gcc 3.4 unterstützten CFLAGS wie -march=pentium-m setzen, falls nocheinmal gcc 3.3.6 übersetzt wird geht das nämlich daneben.
> 
> 

 

Was ist mit meinen "alten" CFLAGS, muss ich die auskommentieren oder darf ich die lassen?

----------

## amne

 *AntonWert wrote:*   

> Was ist mit meinen "alten" CFLAGS, muss ich die auskommentieren oder darf ich die lassen?

 

Natürlich darfst du die behalten.  :Very Happy: 

----------

## tuxian

Die kannst du auf jeden Fall so lassen wie sie sind!

----------

## SinoTech

 *AntonWert wrote:*   

>  *amne wrote:*   Warnung: Bitte jetzt noch keine neuen, nur von gcc 3.4 unterstützten CFLAGS wie -march=pentium-m setzen, falls nocheinmal gcc 3.3.6 übersetzt wird geht das nämlich daneben.
> 
>  
> 
> Was ist mit meinen "alten" CFLAGS, muss ich die auskommentieren oder darf ich die lassen?

 

Die darfst du lassen da der neue gcc Abwärtskompatibel ist.

Mfg

Sino

EDIT:

Bähh, zu spät  :Sad: Last edited by SinoTech on Mon Dec 12, 2005 7:16 pm; edited 1 time in total

----------

## amne

tuxian, SinoTech: Zu langsam. Ätsch!  :Razz: 

----------

## SinoTech

 *amne wrote:*   

> tuxian, SinoTech: Zu langsam. Ätsch! 

 

Fast zeitgleich drei antworten ... damit rechnet natürlich keiner  :Wink: 

Mfg

Sino

----------

## mastacloak

Heyho,

wenn ich die Funktionsweise von ccache richtig verstanden habe, dann kann ich

doch vor dem Wechsel auf gcc-3.4.4 mein ccache-Verzeichnis vollständig löschen?

Oder bringen mir die vom gcc-3.3.6 gecachten Anfragen noch irgendetwas?

Und danach löschen wäre ja blöd, dann sind die gecachten gcc-3.4.4 Sachen ja auch weg.

Und wenn ich diese Zeilen

 *Quote:*   

> The basic idea is to detect when you are compiling exactly the same code a 2nd time and use the previously compiled output. You detect that it is the same code by forming a hash of:
> 
>     * the pre-processor output from running the compiler with -E
> 
>     * the command line options
> ...

 

aus [1] richtig übersetze, dann ist es sinnvoll vor jedem Compilerwechsel und

sei es nur von gcc-x.y.z auf gcc-x.y.z-r1 das Cache-Verzeichnis zu löschen, oder?

[1] http://ccache.samba.org/ccache/ccache-man.html

----------

## ixo

Hallo,

ich habe auf gcc 3.4.4 wie hier beschreiben umgegestellt. Im großen Ganzen ist das auch gut gegangen (ein paar Pakete wollten sich nicht übersetzen lassen, die habe ich gelöscht, weil es Programme waren, die ich nicht wirklich brauchte).

Die einzige zusätzliche Änderung, die ich vorgenommen habe, war:

```
CFLAGS="-O2 -mcpu=athlon-4 -fomit-frame-pointer -ffast-math -pipe"
```

auf

```
CFLAGS="-O2 -march=athlon-4 -fomit-frame-pointer -ffast-math -pipe"
```

geändert, weil der Compiler dann glücklicher war. Mein Rechner ist ein:

```
vendor_id       : AuthenticAMD

cpu family      : 6

model           : 3

model name      : AMD Duron(tm)

stepping        : 1

cpu MHz         : 801.485

cache size      : 64 KB
```

also nicht gerade das schnellste (keine cpu Bugs bei /proc/cpuinfo).

Nach der Installation liefer alle möglichen Programme nicht mehr. Vor ein paar Tagen habe ich dann nochmals ein Update (emerge --update --deep  world) gefahren, bei dem z.B. kde auf Version 3.4.3 neu compiliert wurde. Beim Einloggen stürzen folgende Programme mit signal 4 (SIGILL) ab: KCMInit, KWin, kicker, konqueror, firefox.

Wenn ich top starten will, bekomme ich Illegal instruction.

Ich habe den Verdacht, dass es an libpthread liegt, weil die bei den kde-Fehlermeldungen immer 'mal wieder auftaucht. Welches Packet müsste man neu übersetzen, um libpthread neu zu erzeugen (sys-libs/glibc habe ich auf Verdacht schon 'mal neu übersetzt, hat aber gebracht.) Allerdings wurde libpthread auch neu angelegt (ls -l), wurde also wohl auch neu übersetzt!

Weiß jemand Rat!?

Ach ja, auf meinem Server hat die Umstellung nach derselben Vorgehensweise problemlos geklappt (da läuft z.B. auch top problemlos).

----------

## SinoTech

 *ixo wrote:*   

> 
> 
> [...]
> 
> Wenn ich top starten will, bekomme ich Illegal instruction.
> ...

 

Evtl. ein falscher Eintrag bei den CFlags? Probier mal:

```

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=athlon-tbird -O2 -pipe -fomit-frame-pointer"

CXXFLAGS="${CFLAGS}"

```

Siehe auch: Safe_Cflags

Mfg

Sino

----------

## amne

 *ixo wrote:*   

> 
> 
> Die einzige zusätzliche Änderung, die ich vorgenommen habe, war:
> 
> ```
> ...

 

Stimmt, mcpu geht nicht mehr, das habe ich vorne hinzugefügt.

 *ixo wrote:*   

> 
> 
> ```
> model name      : AMD Duron(tm)
> 
> ...

 

So ein Ding hatte ich auch (bis das Mainboard abgeraucht ist), ich hatte immer -march=athlon. 

 *man gcc wrote:*   

>  athlon-4, athlon-xp, athlon-mp
> 
>      Improved AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and full SSE instruction set support.
> 
> 

 

Taucht bei #grep flags /proc/cpuinfo auch wirklich sse in den Flags auf? Kann ich mir nicht vorstellen. Falls ich recht habe, nimm -march=athlon. Und tu das -ffast-math weg, das bringt nix ausser Ärger (siehe auch hier).

Dann würde ich glibc und gcc neu bauen und die defekten Pakete neu mergen.

----------

## ixo

```
# grep flags /proc/cpuinfo

flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
```

liefert also tatsächlich kein sse

Komisch nur, dass es vorher nie irgendwelche Probleme gab  :Question: 

Naja, dann werde ich 'mal wieder einige Tage (4-5) kompilieren   :Crying or Very sad: 

Jedenfalls vielen Dank für die Tipps, irgend so etwas hatte ich mir fast gedacht.

----------

## amne

Ja, dann würde ich es einmal mit athlon (bzw athlon-tbird wie SinoTech meinte) versuchen.

Vermutlich optimiert gcc 3.3.x nicht so gut, wodurch weniger bis keine Codefragmente entstehen, die Probleme verursachen.

----------

## slick

Was ich noch nicht ganz verstehe, meine alsa-driver mögen mich nicht mehr. Ausgaben dmesg:

```
snd_seq_device: version magic '2.6.11-gentoo-r6 preempt PENTIUMIII 4KSTACKS gcc-3.3' should be '2.6.11-gentoo-r6 preempt PENTIUMIII 4KSTACKS gcc-3.4'

snd_timer: version magic '2.6.11-gentoo-r6 preempt PENTIUMIII 4KSTACKS gcc-3.3' should be '2.6.11-gentoo-r6 preempt PENTIUMIII 4KSTACKS gcc-3.4'
```

Und das obwohl Kernel als auch alsa-driver mit dem 3.4er kompiliert wurden. (und auch von dem Kernel gebootet) Was habe ich übersehen?

----------

## amne

Symlink in /usr/src stimmt? Versuch mal make clean vor dem Kernel kompilieren (war bei mir nicht notwendig).

----------

## slick

Symlink paßt und ein make mrproper hat mir vorher alles gesäubert. (denke ich zumindest)

Und der richtige gcc wird auch verwendet (der einzige auf dem System)

```
# gcc-config -L

/usr/lib/gcc/i686-pc-linux-gnu/3.4.4
```

----------

## SinoTech

Also der Kernel scheint korrekt kompiliert zu sein. Was Probleme macht sind die Alsa-Module, da die aus irgend einem Grund noch mit dem alten gcc-3.3.X kompiliert wurden.

Probier mal ein 

```

$ emerge -c alsa-driver

$ emerge alsa-driver

```

Mfg

Sino

----------

## slick

Bringt auch nichts. Ich habe sogar die Hardcore-Variante probiert und alles in /lib/modules/`uname -r`/alsa-driver/  gelöscht und alsa-driver neu gemergt. Dann kam mir die Idee das evt. distcc daran schuld sein könnte. Also um sicher zu gehen distcc komplett entfernt und alsa-driver neu installiert. Wieder das gleiche  :Sad:  Auch remergt von alsa-utils alsa-headers alsa-oss hat nichts gebracht. Was ich mich frage woher er den gcc-3.3 nehmen will, der ist gar nicht mehr  installiert!

```
# equery l gcc

[ Searching for package 'gcc' in all categories among: ]

 * installed packages

[I--] [  ] sys-devel/gcc-3.4.4-r1 (3.4)

[I--] [M ] sys-devel/gcc-config-1.3.12-r4 (0)
```

----------

## SinoTech

Ganz sicher das er die richtigen Module lädt? Nach dem löschen von 

```

/lib/modules/`uname -r`/alsa-driver/

```

sollte das laden der Alsa-Module eigentlich nicht funktionieren. Falls doch, steckt da irgendwo der Fehler.

Viel mehr fällt mir dazu im Moment leider auch nicht ein  :Sad: .

Mfg

Sino

----------

## slick

Nein, nein, das löschen war nur dafür gedacht das ich auch wirklich sicherstelle das beim emerge die neuen Files da landen. Ansonsten denke ich bisher es liegt daran das ich Alternative 1 gewählt habe und noch kein emerge -e system|world gemacht habe. revdep-rebuild läuft gerade nochmal, ich vemute da wurde was übersehen.

EDIT: revdep-rebuild bringt nix ...

----------

## SinoTech

Schon klar, aber wäre interessant zu sehen ob er die Module wirklich nicht mehr laden kann nach dem sie gelöscht wurden. Denn durch das erneute emergen der alsa-driver sollten die Module bereits mit dem neuen Compiler übersetzt worden sein. Falls nicht, drängt sich der verdacht auf das irgendwo noch alte Module auf deinem System liegen die immer geladen werden.

Auch die Ausgabe von "locate snd_seq_device.ko" wäre interessant. Nur um zu sehen wo sich möglicherweise noch überall eine Instanz dieses Moduls befindet.

Mfg

Sino

----------

## slick

Nachdem ich jetzt /lib/modules/`uname -r` komplett gelöscht habe, den Kernel sowie die alsa-driver neu compiliert habe ging es.  :Smile:  Vermutlich war in /lib/modules/`uname -r` noch irgendetwas altes gewesen was nicht upgedatet wurde.

----------

## SinoTech

 *slick wrote:*   

> Nachdem ich jetzt /lib/modules/`uname -r` komplett gelöscht habe, den Kernel sowie die alsa-driver neu compiliert habe ging es.  Vermutlich war in /lib/modules/`uname -r` noch irgendetwas altes gewesen was nicht upgedatet wurde.

 

Na dann herzlich willkommen in der "Ich bin auf gcc-3.4 umgestiegen und habe es überlebt"-Gruppe  :Very Happy: 

Mfg

Sino

----------

## Anarcho

So, nachdem nun der gcc, libtool, glibc usw. ein paarmal neu emerged wurden und somit die toolchain mit dem gcc 3.4 und march=pentium-m übersetzt worden ist, freue ich mich jetzt auf das Ende von emerge -e world: 749 Pakete....

Ich berichte dann nächste Woche weiter   :Shocked: 

----------

## mrsteven

Ui, da ist es vielleicht besser erstmal gründlich auszumisten...  :Shocked:  Das ist ein Scherz, oder?  :Wink: 

----------

## Anarcho

 *mrsteven wrote:*   

> Ui, da ist es vielleicht besser erstmal gründlich auszumisten...  Das ist ein Scherz, oder? 

 

Ich hab schon mittels depclean 70 Pakete rausgeschmissen und vorher manuell durchs world-file geguckt.

Was aber auch ne Rolle spielt ist das ich das modulare Xorg 7.0 verwende. Das sind ja einige Pakete.

BTW.: nur noch 322 Pakete, dann bin ich fertig!

EDIT:

So, bin nun fertig! Alles läuft und ich bin glücklich.

Der neue GCC scheint sogar deutlich schneller zu sein:

```
     Sun Oct  2 17:56:37 2005 >>> sys-libs/glibc-2.3.5-r1

       merge time: 1 hour, 5 minutes and 11 seconds.                        <- mit gcc 3.3

     Fri Jan 20 12:24:40 2006 >>> sys-libs/glibc-2.3.5-r2

       merge time: 41 minutes and 24 seconds.                                <- erstemal mit gcc 3.4

     Fri Jan 20 13:11:45 2006 >>> sys-libs/glibc-2.3.5-r2

       merge time: 40 minutes and 6 seconds.                                  <- zweitemal mit gcc 3.4, diesmal mit gcc 3.4 kompilierten gcc 3.4

     Fri Jan 20 18:52:39 2006 >>> sys-libs/glibc-2.3.5-r2

       merge time: 33 minutes and 18 seconds.                                <- 3. mal mit gcc 3.4, diesmal mit optimierten gcc und glibc
```

----------

## bookwood

Nach dem auf 2 Maschinen die Umstellung geklappt hat, ist es auf meinem Laptop schief gegangen. Ich bin nach der Anleitung http://de.gentoo-wiki.com/Gcc_updaten vorgegangen (die ~x86 Flags habe ich nicht gesetzt - die Anleitung ist ja etwas älter). Nach der Umstellung auf gcc 3.4.4 habe ich mit:

```
emerge gcc glibc binutils && emerge system -e && emerge world -e
```

das neucompilieren eingeleitet. Mitten im "emerge -e system" stoppte emerge nach ca 70 Packeten mit einer  

```
/bin/bash: symbol lookup error: /usr/lib/libsandbox.so: undefined symbol: __builtin_mempcpy
```

 Meldung. Bei einem erneuten emerge -system bekomme ich dieselbe Meldung:

```
skywalker ~ # emerge -e system

Calculating system dependencies ...done!

>>> emerge (1 of 194) sys-devel/patch-2.5.9 to /

>>> md5 files   ;-) patch-2.5.9.ebuild

>>> md5 files   ;-) patch-2.5.9-r1.ebuild

>>> md5 files   ;-) files/digest-patch-2.5.9

>>> md5 files   ;-) files/digest-patch-2.5.9-r1

>>> md5 files   ;-) files/patch-2.5.9-cr-stripping.patch

>>> md5 src_uri ;-) patch-2.5.9.tar.gz

/bin/bash: symbol lookup error: /usr/lib/libsandbox.so: undefined symbol: __builtin_mempcpy

```

egal welches Packet ich versuche zu emergen, ich bekomme immer die selbe Fehlermeldung. Nichtmal bootstrap.sh läuft noch. Im Netz habe ich ausser unbeantworteten Fragen nichts gefunden. Hier nochmal meine GCC Einstellung

```
skywalker ~ # gcc-config -l

 [1] i686-pc-linux-gnu-3.3.6

 [2] i686-pc-linux-gnu-3.3.6-hardened

 [3] i686-pc-linux-gnu-3.3.6-hardenednopie

 [4] i686-pc-linux-gnu-3.3.6-hardenednopiessp

 [5] i686-pc-linux-gnu-3.3.6-hardenednossp

 [6] i686-pc-linux-gnu-3.4.4 *

 [7] i686-pc-linux-gnu-3.4.4-hardened

 [8] i686-pc-linux-gnu-3.4.4-hardenednopie

 [9] i686-pc-linux-gnu-3.4.4-hardenednopiessp

 [10] i686-pc-linux-gnu-3.4.4-hardenednossp

```

und die Useflags:

```
skywalker ~ # emerge --info

Portage 2.0.54 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-gentoo-r2 i686)

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

System uname: 2.6.14-gentoo-r2 i686 Intel(R) Pentium(R) III Mobile CPU      1133MHz

Gentoo Base System version 1.6.13

distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]

ccache version 2.3 [enabled]

dev-lang/python:     2.3.5-r2, 2.4.2

sys-apps/sandbox:    1.2.12

sys-devel/autoconf:  2.13, 2.59-r6

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

sys-devel/binutils:  2.16.1

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O3 -march=pentium3 -pipe "

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"

CXXFLAGS="-O3 -march=pentium3 -pipe "

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig ccache distcc distlocks sandbox sfperms strict"

GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/"

LINGUAS="de en"

MAKEOPTS="-j5"

PKGDIR="/usr/portage/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/gentoo-de /usr/local/portage"

SYNC="rsync://10.1.1.128/gentoo-portage"

USE="X Xaw3d aalib acl alsa apache apache2 apm arts audiofile avi berkdb bitmap-fonts bonobo bzip2 cdr crypt cups curl doc dvd dvdread eds emboss encode esd ethereal exif expat f77 fam ffmpeg flac foomaticdb fortran gd gdbm gif gimp gimpprint glut gmp gnome gpm gstreamer gtk gtk2 gtkhtml idn imagemagick imlib inkjar ipv6 java jpeg kdbg kde kdeenablefinal kdesdk lcms ldap libg++ libwww lm_sensors mad mhash mikmod mmx mng motif mozilla mozsvg mozxmltermi mp3 mpeg mysql ncurses nls nptl nptlonly nvidia odbc ogg oggvorbis openal opengl oss pam pcre pdflib perl php plugin png postgres postgresql python qt quicktime readline ruby samba sdl slang snmp spell sql sse ssl svg svga tcltk tcpd tetex threads tiff truetype truetype-fonts type1-fonts udev v4l v4l2 vorbis wmf x86 xine xinerama xml2 xmms xprint xv xvid zlib linguas_de linguas_en userland_GNU kernel_linux elibc_glibc"

Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS

```

Ich bin mit meinem Latein am Ende   :Crying or Very sad:  . Für jede Hilfe bin ich dankbar.

----------

## bookwood

Ich habe die Library /usr/lib/libsandbox.so von einer der beiden Maschinen bei denen es geklappt hat rüberkopiert - jetzt geht wieder alles   :Very Happy:  . Ich werde jetzt nach der Anleitung  http://www.gentoo.org/doc/en/gcc-upgrading.xml vorgehen - die ist aktueller.

----------

## a.forlorn

Habe wie in der Anleitung alles gemacht. Leider hat der Wechsel via gcc-config nicht hingehauen. Ich bekomme:

```
env-update

/usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
```

ein paar infos:

```
emerge --info

/usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

```

 :Laughing: 

```
gcc-config -l

 [1] i386-pc-linux-gnu-3.3.5-20050130

 [2] i386-pc-linux-gnu-3.3.5-20050130-hardened

 [3] i386-pc-linux-gnu-3.3.5-20050130-hardenednopie

 [4] i386-pc-linux-gnu-3.3.5-20050130-hardenednopiessp

 [5] i386-pc-linux-gnu-3.3.5-20050130-hardenednossp

 [6] i686-pc-linux-gnu-3.4.4 *

 [7] i686-pc-linux-gnu-3.4.4-hardened

 [8] i686-pc-linux-gnu-3.4.4-hardenednopie

 [9] i686-pc-linux-gnu-3.4.4-hardenednopiessp

 [10] i686-pc-linux-gnu-3.4.4-hardenednossp
```

```
gcc-config -f 1

 * Switching cross-compiler to i386-pc-linux-gnu-3.3.5-20050130 ...

 * env-update failed to work properly; making sure ld.so.conf paths

 * are setup properly.  Please rerun gcc-config with the -f option.

                                                                          [ ok ]

 * If you intend to use the gcc from the new profile in an already

 * running shell, please remember to do:

 *   # source /etc/profile
```

Zurückswitchen geht nicht. gentoolkit habe ich nicht drauf, da ich emerge -e world plannte.

----------

## amne

Ich komm jetzt nicht ganz mit, was hast du gemacht und wann geht was nicht? gcc 3.3.5 ist noch installiert?

----------

## a.forlorn

 *amne wrote:*   

> http://dev.gentoo.org/~avenj/bins/i686/ has a tbz for gcc-3.3.4-r1.tbz2. Since emerge is broken you should just unpack it with tar. This should provide the missing libs and make emerge work again. If it works, emerge -k gcc 3.3.4-r1 again from the binary package (so portage is aware of it), gcc-config to 3.4.4 and do the upgrade. I hope things should work like that.

 

Mach grad den Vorschlag aus deinem englischen Beitrag. Soweit so gut. (ist nur ein C3 1000Mhz, der braucht ein wenig.

Ich gehe so vor: 

```
1. emerge --sync && emerge -u gcc && gcc-config i686-pc-linux-gnu-3.4.4 && source /etc/profile

2. gcc-config -l

3. emerge gcc binutils glibc libstdc++-v3 && emerge -P gcc && emerge -e system && emerge -e world
```

----------

## mondauge

Danke für die Umstellungsanleitung.. Damit war das einigermaßen schmerzlos und unkompliziert durchzuziehen  :Smile:  Eine Frage hätte ich aber noch:

Ich habe auf meinem Gentoo daheim auch ein paar Programme drauf, bei denen beim mergen eine Lizenz manuell akzeptiert werden muss. Prinzipiell kein Problem, doch beim mergen von 400 Paketen lass ich die Kiste doch gerne mal laufen und geh dann weg. Jetzt ist es leider ziemlich ärgerlich, wenn man wieder kommt und feststellt, dass er 20 von den 400 Pakete gemergt und den Rest der Zeit wegen der blöden Lizenz gewartet hat. Gibt es einen Weg, diese Pakete bei "emerge -e" vorher wegzufiltern?

schöne Grüße,

mondauge

----------

## slick

ungetestet, in etwa so:

```
emerge gentoolkit

for paket in `equery l` ; do

  if [ "${paket}" != "app-misc/app_with_license" ] ; then

    all="${all} =${paket}"

  fi

done

emerge --oneshot $all

emerge app-misc/app_with_license
```

----------

## a.forlorn

Läuft wieder alles. Warum es bei ersten mal nicht geklappt hat, weiss ich nicht.   :Confused: 

----------

## Battlestar Gentoo

Vielleicht eine dumme Frage, aber warum muss ich das System eigentlich komplett neu kompilieren, wenn ich auf gcc 3.4 wechsle?

Was bewirkt diese Umstellung?

----------

## tost

Damit auch alle Pakete mit dem neuen Compiler gebaut werden ..

Ansonsten ist ja alles noch mit dem alten, doch wir wollen ja umstellen  :Wink: 

tost

----------

## Battlestar Gentoo

Ja schon, aber ist das so ein Problem?

----------

## amne

Gcc 3.3.x stellt libstdc++.so.5 zur Verfügung, 3.4.x nicht. Daher werden alle gegen diese Lib verlinkten Pakete nach der Umstellung (und unmergen von 3.3.x) nicht mehr funktionieren. Deshalb kannst du entweder diese Pakete mittels revdep-rebuild neu bauen (und dabei gegen 3.4.x verlinken), oder gleich das ganze System neu übersetzen.

Ersteres ist schneller, zweiteres garantiert auch eine saubere Toolchain.

----------

## deejay

Guten Morgen,

ich habe nun auch auf den gcc3.4 umgestellt. Habe die Variante mit revdep-rebuild gewählt. 

Hat einwandfrei funktioniert. Besten Dank...

Gruß

deejay

----------

## Battlestar Gentoo

Noch eine Frage dazu:

Ich habe seit gestern Nacht emerge -e system && emerge -e world laufen

Jetzt in der Früh muss ich bemerken, dass ein emerge -e world sowieso wieder _alles_ komplett neu baut, wobei ich sowieso nicht ganz verstehe, wo plötzlich über 400 zu emergende Pakete herkommen, da emerge -e system ca 120 Pakete hatte, und emerge -uD world 119 Pakete benötigt. Wozu soll emerge -e world also gut sein? Wozu habe ich zuerst emerge -e system ausgeführt, wenn ohnehin bei emerge -e world alles komplett neu gebaut wird? Ich habe es jetzt mal auf ein emerge -uD world beschränkt.

----------

## SinoTech

1. Also wenn du zuvor die Toolchain neu gebaut hast, ist ein "emerge -e system" nicht notwendig.

2. Ein "emerge -e system" baut nur die Pakete neu die im Target "system" sind (u.a. glibc, binutils, gcc, ...)

3. Ein "emerge -uD world" emerged nur die Pakete von denen es Updates gibt (Also nicht wundern das es nicht so viele bei sind).

4. Ein "emerge -e world" emerged das komplette System neu ... und da sind 400 Pakete eher wenig als viel (Bei mir sind im "world" 600 Pakete)

Mfg

Sino

----------

## Battlestar Gentoo

Alles klar, und kann das jetzt aufgrund der verschiedenen gcc-Versionen zu irgendwelchen Komplikationen (vielleicht aufgrund der Abhängigkeiten?) führen, da ich jetzt "nur" emerge -uD world laufen lasse? Immer wären jetzt ein paar Pakete, die nicht zu "system" gehören (da ich sowieso emerge -e system ausführte), sondern nur "Standardsoftware" sind, noch mit gcc 3.3 kompiliert worden, da emerge -uD world nur ein Update macht.

----------

## deejay

was passiert dann bei einem revdep-rebuild?

Habe das wiegesagt schon erfolgreich abgeschlossen, zur Sicherheit nochmal 

laufen lassen, aber er findet keine Pakete mehr, die neu gebaut werden müssten.

Ist ja auch gut so. Ist es sinvoll, jetzt nochmal ein "emerge -e system" zu machen,

oder wäre das jetzt nicht mehr notwendig. System läuft ja jetzt wieder soweit.

Gruß

deejay

----------

## SinoTech

 *Gentoo Reptile wrote:*   

> Alles klar, und kann das jetzt aufgrund der verschiedenen gcc-Versionen zu irgendwelchen Komplikationen (vielleicht aufgrund der Abhängigkeiten?) 
> 
> [...]
> 
> 

 

Ja, kann es (und wird es wahrscheinlich auch früher oder später).

Zumindest ein "revdep-rebuild" solltest du noch ausführen.

Mfg

Sino

P.S.: Und den kernel und Kernel Module neu kompilieren, da der Kernel keine Module mag die mit einer anderen gcc Version gebaut wurden als er selbst.

----------

## SinoTech

 *deejay wrote:*   

> was passiert dann bei einem revdep-rebuild?
> 
> [...]
> 
> 

 

"revdep-rebuild" schaut gegen welche Bibliotheken ein Programm gelinkt wurde, und ob diese noch existieren. Falls nicht, wird das Programm neu ge-merged und gegen die neuen bibliotheken gelinkt. Wenn dein System sauber läuft brauchst du kein "emerge -e system" mehr zu machen.

Mg

Sino

----------

## Battlestar Gentoo

 *Quote:*   

> Ja, kann es (und wird es wahrscheinlich auch früher oder später). 

 

Ok, dann werde ich ein revdep-rebuild danach machen. Das wird dann wahrscheinlich morgen sein, bei der Geschwindigkeit meines 1.8GHz- Rechners  :Smile: 

Übrigens musste ich feststellen, dass torsmo aufgrund angeblicher Nichtwartung nicht mehr in Portage vorhanden ist. (Man solle Conky stattdessen nehmen). Ich habe es einfach so gehandhabt, dass ich es aus dem world-File gelöscht habe, damit emerge -uD world ausgeführt werden kann. Gibt es irgendwelche Probleme, wenn ich so vorgehe und es einfach so lösche, oder hätte ich es anders machen sollen?

(Tormso werde ich später noch deinstallieren)

----------

## deejay

 *SinoTech wrote:*   

>  *deejay wrote:*   was passiert dann bei einem revdep-rebuild?
> 
> [...]
> 
>  
> ...

 

Alles klar. Danke. Dann läuft ja nun wieder alles  :Very Happy: 

Schöne Grüße

deejay

----------

## SinoTech

 *Gentoo Reptile wrote:*   

> 
> 
> [...]Ich habe es einfach so gehandhabt, dass ich es aus dem world-File gelöscht habe, damit emerge -uD world ausgeführt werden kann. Gibt es irgendwelche Probleme, wenn ich so vorgehe und es einfach so lösche, oder hätte ich es anders machen sollen?
> 
> [...]
> ...

 

Also da es nicht mehr im World-File ist, und es auch keine Abhängigkeit eines anderen Paketes ist, wird es bei einem "emerge --depclean" gelöscht werden (Ansonsten sollte es soviel ich weiß keine Probleme geben).

Etwas schöner wäre es gewesen wenn du ein Overlay angelegt und dort das ebuild reinkopiert hättest.

Mfg

Sino

----------

## Battlestar Gentoo

Ok, dane für den Tipp.

Übrigens musste ich leider feststellen, dass der gcc-3.4.4 den nvidia-kernel überhaupt nicht mag. nvidia funktioniert nämlich damit nicht mehr. Ich musste den nvidia-kernel und nvidia-glx wieder mit 3.3.4 kompilieren. Gut, dass ich diese Versionen nicht gelöscht habe.

----------

## SinoTech

 *Gentoo Reptile wrote:*   

> Ok, dane für den Tipp.
> 
> Übrigens musste ich leider feststellen, dass der gcc-3.4.4 den nvidia-kernel überhaupt nicht mag. nvidia funktioniert nämlich damit nicht mehr. Ich musste den nvidia-kernel und nvidia-glx wieder mit 3.3.4 kompilieren. Gut, dass ich diese Versionen nicht gelöscht habe.

 

Also ich hatte mit dem 3.4.4 keine Probleme .. wäre evtl. auch hilfreich wenn du sagst was genau dein Problem ist.

Mfg

Sino

----------

## Battlestar Gentoo

Das nvidia-Modul konnte nicht mehr geladen werden: 

 *Quote:*   

> Error inserting nvidia (/lib/modules/2.6.14.2/video/nvidia.ko): Invalid module format

 

Bei linuxforen.de fand ich einen Eintrag zu diesem Problem. Angeblich hätte der gcc-3.4.4 damit zu tun, und als ich nvidia mit dem alten gcc kompilierte, konnte ich das modul wieder laden. Muss also irgendwie an gcc liegen.

Übrigens benutze ich nvidiakernel 1.0.6629-r5, nvidia-glx 1.0.6629-r6.

----------

## SinoTech

 *Gentoo Reptile wrote:*   

> Das nvidia-Modul konnte nicht mehr geladen werden: 
> 
>  *Quote:*   Error inserting nvidia (/lib/modules/2.6.14.2/video/nvidia.ko): Invalid module format 
> 
> Bei linuxforen.de fand ich einen Eintrag zu diesem Problem. Angeblich hätte der gcc-3.4.4 damit zu tun, und als ich nvidia mit dem alten gcc kompilierte, konnte ich das modul wieder laden. Muss also irgendwie an gcc liegen.
> ...

 

Liegt wohl daran das der Kernel noch mit dem 3.3.X kompiliert wurde  :Wink: . Hättest den Startthread komplett lesen müssen, dort steht nämlich das kernel UND Kernelmodule (Wozu auch NVIDIA gehört) mit dem selben gcc kompiliert werden müssen.

Mfg

Sino

----------

## Battlestar Gentoo

Ach herrje. Daran wird's wahrscheinlich liegen. Ich werd's beim nächsten Kernelupdate, das ohnehin wieder mal fällig wird, gleich ausprobieren.

----------

## deejay

Der nvidia-kernel funktioniert auf jedenfall mit dem gcc3.4.4. Läuft bei mir auch...

Gruß

deejay

----------

## Battlestar Gentoo

So, nun machte ich ein Kernelupdate, aber jetzt habe ich das Dilemma mit nvidia beisammen.

Der Kernel wurde natürlich mit gcc-3.4.4 übersetzt, und nvidia jetzt auch. Jetzt ist es aber so, dass beim Starten des x-Servers der Startvorgang einfach stecken bleibt, und ich nichts anders tun kann, als zu rebooten. 

Ich habe dabei Kernel 2.6.15.1, nvidia 1.0.6629-r5 und nvidia-glx 1.0.6629-r6 mit gcc-3.4.4 übersetzt.

Was soll ich tun außer den Kernel und nvidia mit gcc-3.3.4 zu übersetzen?

----------

## Uncle Enzo

Dieses Problem hatte ich auch.. versuch mal den X mit 3.4.4 zu compilen, bei mir hats funktioniert  :Wink: 

----------

## Battlestar Gentoo

Das System wurde komplett neu mit gcc-3.4.4 kompiliert. Daran kann es also (bei mir) nicht liegen.

----------

## SinoTech

Schau mal hier: X locks up with nvidia-kernel-1.0.8178-r3 and 2.6.15-r1 kernel

Mfg

Sino

----------

## Battlestar Gentoo

Es sind zwar wenige Lösungsansätze vorhanden, aber auf Dinge wie acpi=off würde ich gerne verzichten. 

Desweiteren endet das Posting leider mit dem selben Problem, das ich gerade habe. 

Von anderer Seite habe ich wieder erfahren, dass man den Kernel-2.6.15.1 nicht mehr mit dem nvidia-kernel-1.0.6629-* verwenden kann.

Ich kompiliere nun mal den Kernel und den nvidia-kernel mit 3.3.6, um ganz sicher zu gehen.

Edit:

Das Übersetzen mit dem alten gcc hat nicht funktioniert. Es konnten dann nämlich gar keine Module mehr geladen werden, da wahrscheinlich der Rest des System ja mit 3.4.4 übersetzt wurde.

----------

## Battlestar Gentoo

So, das Problem ist fürs erste gelöst. (zumindest bis wahrscheinlich zum nächsten Kernel-update).

Mir wurde gesagt, dass ich nvidia-kernel-1.0.7174 versuchen solle, und das half dann auch. (nvidia-glx wurde nun in der Version 1.0.7174-r5 installiert). Ich wäre allerdings froh, wenn mich jemand darüber aufklären könnte, warum diese Version so speziell ist.

----------

## buthus

 *Gentoo Reptile wrote:*   

> So, das Problem ist fürs erste gelöst. (zumindest bis wahrscheinlich zum nächsten Kernel-update).
> 
> Mir wurde gesagt, dass ich nvidia-kernel-1.0.7174 versuchen solle, und das half dann auch. (nvidia-glx wurde nun in der Version 1.0.7174-r5 installiert). Ich wäre allerdings froh, wenn mich jemand darüber aufklären könnte, warum diese Version so speziell ist.

 

ich kenn deine graka jetzt nicht. aber das ist die letzte version, mit der noch alle "älteren" grafikkarten ( >tnt2) problemlos funktionieren.

----------

## Battlestar Gentoo

Ich habe eine GForce2 Pro.

Solange der Kernel die alten Treiber schluckt, muss ich nicht die neuesten verwenden. Es wird eben nur dann zum Problem, wenn es dann mal nicht mehr so ist.

----------

## buthus

selbst das ist machbar, man kann mit der nvmakedevice.sh auch alte karten mit den neuesten treibern laufen lassen.

----------

## SinoTech

 *buthus wrote:*   

> selbst das ist machbar, man kann mit der nvmakedevice.sh auch alte karten mit den neuesten treibern laufen lassen.

 

1. Gibt es dieses script bei den neusten Treibern nicht mehr

2. Glaub ich nicht das das reicht um die volle Unterstütztung für die GraKa zu bekommen. Wenn der Treiber die Karte nicht unterstützt, kann dieses Script mit Sicherheit auch nichts daran ändern.

Mfg

Sino

----------

## buthus

hallo sino,

ich weiss das, aber man bekommt trotzdem die karte damit zum laufen. und wenn es nur um die auflösung und die frequenz geht um den monitor anstendig anzusteueren reicht es vollkommen. vieleicht nicht zum spielen da kannst du recht heben. aber der lebende beweis ist hier im forum, er hat einen geforce2 mit dem neusten treiber laufen.

----------

## slick

Thread unsticky

----------

