# [gcc] gcc 3.3.6 -> 3.4.4-r1 : recompil indispensable ?

## dreamer86

J'aimerai savoir si la recompil de tout ce qui dependais de l'ancien gcc est vraiment indispensable ? (revdep-rebuild me sort une liste de 3km de long...  :Sad:  )

Je n'ai pas trop envi de passer plusieurs jours à tout recompiler...   :Confused: 

La recompil au fur et à mesure vers la  libstdc++.so.6 ne suffit-elle pas ? sachant que je n'ai pas fait d'unmerge de l'ancien gcc 3.3.6

----------

## nuts

je dirait qu'une recompille n'est pas necessaire, car la difference sera pas enormement perceptible, et puis ca se fera au fur et a mesur des tes mise a jour...

----------

## dreamer86

Peux t-il y avoir des pb d'instabilités qui peuvent en decouler ?   :Confused: 

----------

## truc

ICI tu pourras trouver un peu le pourquoi du comment (expliqué vite fait quoi...)

 *Halcy0n wrote:*   

>  *DerRalf wrote:*   
> 
> Can someone briefly explain why it is necessary to recompile the system? I switched between compiler versions before and so far didn't run into any problems. What consequences will it have if I switch to the new version and only use if for packages I emerge from now on? 
> 
> GCC-3.3 and GCC-3.4 are not binary compatible when it comes to C++ apps, so things will break when you try to link gcc-3.3 libraries with gcc-3.4 ones.

 

----------

## dreamer86

Si je comprend bien, si on ne recompile pas tout d'un coup, le tout est de conserver gcc 3.3 pour tout les binaires dependant de l'ancienne libstdc++ ?

----------

## lithium

pour la compatibilité tu peut installer le paquet libstdc++v3

----------

## Enlight

emerge -e system && emerge -e system && emerge -e world && emerge -e world est normalement la garantie absolue que les choses iront bien quand on ne veut pas se prendre la tête avec les dépendances circulaires et autres hacks...   :Laughing: 

----------

## xrtds1

J'ai fait un emerge -u world et cela a installer gcc 3.4. Je n'ai rien toucher par la suite et tout va pour le mieux. J'ai compiler Gnome et ces 49 dépendances sans aucun problème.

----------

## _droop_

 *Enlight wrote:*   

> emerge -e system && emerge -e system && emerge -e world && emerge -e world est normalement la garantie absolue que les choses iront bien quand on ne veut pas se prendre la tête avec les dépendances circulaires et autres hacks...  

 

Bonjour, ça c'est sûr, mais faut pas être trop pressé...

Un emerge -e world doit suffir pour régler les problèmes d'incompatibilités binaires.

Bonne journée.

----------

## Faust_

salut,

perso j'ai fait une boulette hier, j'ai mis a jour GCC de la 3.3.6 vers la 3.4.4 tout en delirant avec un pote

apres un joli emerge -C =gcc-3.3.6 (je sais, je sais pas la peine de me dire que j'suis un ane  :Smile:  ), mon systeme avait quelques petits problemes, plus d'emerge entre autre, donc foutu pour installer libstdc++-v3

alors si jamais vous faites la meme boulette (je ne pense pas que vous soyez nombreux mais bon  :Wink:  ), pour m'en sortir j'ai   recupere libstdc++.so.5 dans OpenOffice et je l'ai mis dans /lib

cp /opt/OpenOffice.org/program/libstdc++.so.5 /lib/

ensuite (la c'est long j'ai recompile env 110 ebuilds  :Smile:  )

revdep-rebuild --library libstdc++.so.5 -- -pv 

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

rm /lib/libstdc++.so.5

emerge libstdc++-v3

et tout refonctionne nickel

ce n'est pas genial, c'est long mais ca marche donc c'est bon  :Smile: 

----------

## cylgalad

Tout est expliqué LÀ mais bon c'est en anglais.

En gros si on garde gcc-3.3.6, tout va bien mais si on veut le virer, il faut recompiler tout ce qui utilise libstdc++ (un beau bordel...), déjà recompiler python peut éviter de gros soucis  :Wink: 

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

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

----------

## nuts

je crainds de ne pas tout comprendre. pourquoi garder l'ancien gcc? car au fur et a mesure des update ca sera compillé avec le nouveau gcc non?

----------

## cylgalad

Tous les programmes liés avec libstdc++ ne trouveront plus celui du 3.3.6 et ne seront pas foutus d'utiliser celui du 3.4.4 (alors qu'ils utilisent /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libgcc_s.so.1, va comprendre charles...), donc si tu vires gcc-3.3.6 sans recompiler python, xorg, kde, fluxbox (y'a du C++ dans fluxbox ???), etc..., tu es dans le caca, plus rien ne va fonctionner...

----------

## truc

 *YangFuShang wrote:*   

> J'ai fait un emerge -u world et cela a installer gcc 3.4. Je n'ai rien toucher par la suite et tout va pour le mieux. J'ai compiler Gnome et ces 49 dépendances sans aucun problème.

 

Si c'est tout ce que tu as fait, alors tu utilises toujours gcc-3.3.6... gcc.3.4 s'est juste mis dans un slot différent mais encore faut-il que tu lui indiques de l'utiliser... (cf doc y'en a assez:) )

----------

## bong

 *truc wrote:*   

> Si c'est tout ce que tu as fait, alors tu utilises toujours gcc-3.3.6... gcc.3.4 s'est juste mis dans un slot différent mais encore faut-il que tu lui indiques de l'utiliser... (cf doc y'en a assez:) )

 

Visiblement, chez moi ca a pas été le cas, juste apres un

```
emerge -u gcc && source /etc/profile && gcc-config -l
```

voila ce que j'ai eu:

```
 [1] i686-pc-linux-gnu-3.3.4

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

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

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

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

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

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

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

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

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

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

```

allez comprendre...

j'ai installé la libstdc++-v3 et fais un emerge -e system

Pour le reste, ca passera avec les maj.. j'ai pas envie de me taper la compil de 1,2Go de sources   :Confused: 

----------

## Enlight

 *_droop_ wrote:*   

>  *Enlight wrote:*   emerge -e system && emerge -e system && emerge -e world && emerge -e world est normalement la garantie absolue que les choses iront bien quand on ne veut pas se prendre la tête avec les dépendances circulaires et autres hacks...   
> 
> Bonjour, ça c'est sûr, mais faut pas être trop pressé...
> 
> Un emerge -e world doit suffir pour régler les problèmes d'incompatibilités binaires.
> ...

 

Et bien malheuresement non, l'upgrading guide est ce qu'il est car seule l'ABI des programmes en C++ est incompatible, mais dans le cas où il y'aurait des modifications mineures d'ABI des programmes C (pas une incompatibilité sinon c'est cross-compile direct) afin d'éviter certains effêts de bord c'est la seule méthode sure, dans la mesure où portage ne sait pas appréhender les dépendances circulaires.

Genre : 

-----------------------------------------------------

gcc veut les libc headers

les libc headers ont besoin des kernels headers

et les kernels headers ont besoin de gcc

------------------------------------------------------

il'y'en a d'autre de ce genre avec java, perl ... à moind de connaître chacune, la solution que je donne reste (malheuresement) le seul moyen d'avoir un système entièrement propre (c.a.d sans se retrouver avec un programme compilé avec gcc X.Y.Z qui aurait répliqué en static du code encore compilé avec une version inférieure etc...)

----------

## TGL

 *cylgalad wrote:*   

> En gros si on garde gcc-3.3.6, tout va bien

 

Non, tout ne va pas exactement bien. Par exemple, la liaison d'un programme C++ compilé par gcc-3.4 avec une bibliothèque compilée par gcc-3.3 peut s'avérer installable à cause des différence d'ABI. Conserver gcc-3.3 ou installer la libstdc++v3 est bel et bien indispensable tant qu'on a encore du C++ compilé par gcc-3.3, mais ça n'est pas pour autant suffisant à partir du moment où on commence à effectivement utiliser gcc-3.4 pour des mises à jour et compagnie.

Bref, le guide d'upgrade ne sert pas qu'à se débarrasser de gcc-3.3 : il faut vraiment le suivre dès lors qu'on décide d'utiliser gcc-3.4.

 *Enlight wrote:*   

> Et bien malheuresement non, l'upgrading guide est ce qu'il est car seule l'ABI des programmes en C++ est incompatible, mais dans le cas où il y'aurait des modifications mineures d'ABI des programmes C (pas une incompatibilité sinon c'est cross-compile direct) afin d'éviter certains effêts de bord c'est la seule méthode sure, dans la mesure où portage ne sait pas appréhender les dépendances circulaires.

 

Des dépendances circulaire, il n'est pas censé y en avoir en dehors des paquets de la classe "system". Donc recompiler ceux là deux fois, oui, mais "world" par contre, franchement ça sert à rien... D'où le "emerge -e system && emerge -e world" du guide d'upgrade, qui fait exactement ça (puisque "-e world" inclue "system").

----------

## dreamer86

En gros, on est vraiment obligé de passer plusieurs jours à tout recompiler quoi ?   :Confused: Last edited by dreamer86 on Sun Dec 04, 2005 4:52 pm; edited 1 time in total

----------

## Enlight

 *TGL wrote:*   

> 
> 
> Des dépendances circulaire, il n'est pas censé y en avoir en dehors des paquets de la classe "system". Donc recompiler ceux là deux fois, oui, mais "world" par contre, franchement ça sert à rien... D'où le "emerge -e system && emerge -e world" du guide d'upgrade, qui fait exactement ça (puisque "-e world" inclue "system").

 

C'est exactement la reflexion que j'avais faite, mais certains devs m'ont assuré qu'il fallait 2 fois le world celà dit pour les membre de system ça me surprendrais également qu'un programme nécéessite plus de 3 passes.

----------

## TGL

 *Enlight wrote:*   

> C'est exactement la reflexion que j'avais faite, mais certains devs m'ont assuré qu'il fallait 2 fois le world

  Peut-être qu'on peut trouver des cas théoriques où une 2ème passe sur certains paquets non-système s'avèrerait nécéssaire, mais sérieux je doute que ça affecte 1% des utilisateurs. La discussion sur gentoo-dev@ à propos de la méthode de migration à préconiser à d'ailleurs été assez longue, mais personne n'y a pour autant ne serait-ce que suggéré d'ajouter un 2ème "emerge -e world". À mon humble avis, c'est pas parcequ'on peut trouver des devs à bi-Athlon64 / 4Go RAM qui font des "emerge -e world" quotidiens juste au cas où qu'il faut forcement faire pareil.

Bref mon conseil reste de suivre le guide d'upgrade à la lettre, et d'aviser ensuite dans le cas très improbable où il s'avèrerait insuffisant.

----------

## Enlight

Je crois qu'en fait le but c'était quand on ne touche pas directement aux paquets, de compiler 2 fois le système avant toute autre chose histoire qu'il soit propre, puis une fois qu'il est ok, recompiler le reste 2 fois "au cas où y'aurait des dépendances circulaires" mais comme on peut pas faire emerge world - system, ben ça fait builder 4 fois le system.

Et là, comme toi je suis sceptique au minimum sur le 2è system et premier world puisque logiquement tout ce qui appartient à system est fait en premier dans un emerge world. 

Mais bon en l'occurence la transition 3.3.6 à 3.4.4 n'est normalement pas aussi exigente, faudra un jour traverser les makefiles histoire de connaître le fin mot de l'histoire.

----------

