# [Résolu] [GCC] Mise à jour de GCC 3.4.5 => 4.1.1

## Link31

Salut,

Dans le guide de migration de GCC, il est indiqué qu'il faut faire un emerge -e system puis world... C'est que ce n'est pas anodin ça, 26-27h de compilation...

Mais les changements ne concernent que la libstdc++, donc ne concernent que les programmes en C++, non ?

J'ai fait un revdep-rebuild --library libstdc++.so.6 --pretend, et il me trouve nettement moins de paquets (enfin il y en a quand même pas mal...). Est-ce possible de ne recompiler que ces paquets-là après être passé au GCC 4.1.1 ? Ou alors il faudra quand même tout recompiler ?  :Confused: 

Autre question : est-il nécessaire de recompiler le noyau aussi ?

Merci.Last edited by Link31 on Tue Oct 31, 2006 10:46 pm; edited 1 time in total

----------

## Temet

Recompile tout, y compris le noyau  :Wink: 

----------

## kopp

Recompiler que contre libdistcc++ peut être suffisant, mais ça peut aussi causer des problèmes, c'est pour ça que le guide propose de tout recompiler.

J'ai aussi vu des méthodes qui proposent d'autres approchents au problem sur le forum. Je vais voir si j'arrive à retrouver ça.

Pour le noyau, je dirais de le recompiler, car certain modules externes risquent d'être recompilés, et ça va faire du caca après  :Smile: 

----------

## d2_racing

À mon avis, tu est mieux de suivre le howto,car tu vas être sur que ton système va utiliser le nouveau compilateur...

C'est long 26-27 heures, mais tu vas le faire une fois et tout devrait être correct...par contre si tu fait des passes passes pour éviter de tout recompiler, peut-être que tu vas travailler plus pour réparrer les pots cassés  :Smile: 

----------

## kopp

Ok ok je garde mes solutions alembiquées pour moi alors. Tant mieux j'avais la flemme de chercher.

Pour les autres, il y a deux articles reliés, un dans Documentation, Tips and Tricks à propos des recompilation de GCC etc, et l'autre dans Unsupported software, par le même auteur.

----------

## Link31

OK, je suis bon pour le emerge -e alors...

Comme je ne vais probablement pas être à côté du PC pendant 27h, je pourrais lancer un script dans ce genre :

```
emerge -e world

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst

emerge --resume --skipfirst
```

Est-ce une bonne idée ? Les ebuilds qui ne passeront pas risquent d'en bloquer d'autres... Et comment pourrais-je récupérer de façon automatique les noms des ebuilds qui ont planté, ainsi que l'erreur associée (si possible) ?

----------

## kopp

Il y avait une solution dans une GWN récente avec l'utilisation d'until, pour faire des skipfirst jusqu'a que ce soit fini.

Sinon, ça risque d'être problématique...

Pour récupérer la liste des ebuilds qui ont planté, tu peux comparé un emerge world avec la liste des derniers paquets installés (obtenue avec genlop)

----------

## Link31

Je viens de trouver ça : https://forums.gentoo.org/viewtopic-t-494331.html

Apparemment c'est ce qu'il me faut  :Very Happy: 

Sinon il y a aussi la solution de genlop, en effet, je n'y avais pas pensé  :Wink: 

----------

## kopp

C'est ce dont je parlais. Il y a un lien vers une de ses explications dans le début du sujet, qui est intéressant aussi.

----------

## Link31

Hem... petit problème. J'ai changé le compilateur par défaut pour compiler avec GCC 4.1.1, mais je ne peux plus compiler :

```
link31@linux ~$ cat helloworldc++.cpp

#include <iostream>

using namespace std;

int main(int argc, char* argv[])

{

        cout << "Hello world !" << endl;

        return 0;

}

link31@linux ~$ g++ helloworldc++.cpp -o helloworldc++

/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libc.so: file format not recognized; treating as linker script

/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libc.so:5: syntax error

collect2: ld a retourné 1 code d'état d'exécution
```

Évidemment, difficile dans ces conditions de faire un emerge -e world...

Je précise que j'ai mis à jour la Glibc juste en même temps que j'ai mis à jour le GCC, mais après. Elle a donc été compilée par le GCC 3.4.5. Je ne sais pas si ça vient de là...

----------

## Mickael

C'est quoi :

 *Quote:*   

> cat helloworldc++.cpp 

 

Maintenant :

 *Quote:*   

> Je précise que j'ai mis à jour la Glibc juste en même temps que j'ai mis à jour le GCC, mais après. Elle a donc été compilée par le GCC 3.4.5. Je ne sais pas si ça vient de là...

 

Si j'ai bien  compris, tu as mis à jour ta glibc puis tu as fait la mise à jour de gcc. Donc si tu as suivi le howto ainsi que les conseils précents, tu as fais un emerge -e system ? non?

----------

## Link31

 *MickTux wrote:*   

> C'est quoi :
> 
>  *Quote:*   cat helloworldc++.cpp  

 

C'est juste pour montrer que l'erreur ne vient pas de mon helloworldc++.cpp, mais bien du compilateur. J'ai peut-être écrit une bêtise dans le code ? Quoi qu'il en soit, plus rien ne compile avec ce nouveau GCC, même pas les emerge ou d'anciens codes qui fonctionnaient avant. Les codes en C ne passent pas non plus...  :Confused: 

 *MickTux wrote:*   

> Si j'ai bie compris, tu as mis à jour ta glibc puis tu as fait la mise à jour de gcc. Donc si tu as suivi le howto ainsi que les conseils précents, tu as fais un emerge -e system ? non?

 

En fait j'ai voulu faire l'update de GCC, et 'ai vu qu'il voulait aussi recompiler la glibc (à cause d'un nouvel useflag). Donc je me suis dit, tant qu'à faire, autant mettre à jour aussi ma glibc qui était un peu dépassée (2.3.6 => 2.4). Ce qui fait que GCC 3.4.5 a compilé le GCC 4.1.1 puis la glibc 2.4.

Ensuite j'ai fait un gcc-config pour choisir le GCC 4.1.1, et plus rien ne compile ! Donc le emerge -e world (en fait un script trouvé ici) ne fonctionne plus.

----------

## Mickael

T'aurais suivi le guide !!! tout serait terminé depuis longtemps... T'as pas été fûté sur ce coup là : tu emerge gcc, puis tu pointes dessus, puis tu fais des mises à jour afin d'éviter à recompiler 2 fois les mises à jour. Si tu n'as pas viré encore l'ancier gcc, pointe de nouveu dessus, puis suit la marche dans le guide de gcc. Il n'y a pas de raison pour que tous les paquets plantes, vérifie juste de temps en temps que le emerge -e ne s'est pas arrêté. Je sais pas pourquoi tu t'es compliqué la vie?

----------

## Link31

Merci de ta réponse mais ça ne fonctionne toujours pas, malgré le fix_libtool indiqué dans le guide. En supposant que c'est un problème avec la glibc, je ne peux plus installer le paquet binaire que j'avais fait de la 2.3.6. As-tu une idée de l'origine du problème ?

Une précision : /usr/lib64/libc.so est un script :

```
/* GNU ld script

   Use the shared library, but some functions are only in

   the static library, so try that secondarily.  */

OUTPUT_FORMAT(elf64-x86-64)

GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a  AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) )

```

Il me dit qu'il y a une erreur de syntaxe à la ligne 5. Peut-être qu'en corrigeant ça il acceptera enfin de compiler ?

----------

## Mickael

Que donne 

```
gcc-config -l
```

----------

## Link31

```
linux ~ # gcc-config -l

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

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

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

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

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

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

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

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

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

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

 [11] x86_64-pc-linux-gnu-3.4.5

 [12] x86_64-pc-linux-gnu-3.4.5-hardened

 [13] x86_64-pc-linux-gnu-3.4.5-hardenednopie

 [14] x86_64-pc-linux-gnu-3.4.5-hardenednopiessp

 [15] x86_64-pc-linux-gnu-3.4.5-hardenednossp

 [16] x86_64-pc-linux-gnu-4.1.1 *
```

```
linux ~ # gcc-config --get-current-profile

x86_64-pc-linux-gnu-4.1.1
```

Mais ça ne fonctionne pas non plus quand je sélectionne le 3.4.5...

----------

## Mickael

que retourne maintenant :

```
emerge -v glibc
```

----------

## Link31

Il y a un peu de progrès : j'ai enlevé "AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 )" du /usr/lib64/libc.so et maintenant j'arrive à compiler des helloworlds avec le 4.1.1.

Mais la Glibc ne passe toujours pas...

 *MickTux wrote:*   

> que retourne maintenant :
> 
> ```
> emerge -v glibc
> ```
> ...

 

```
...

checking for inttypes.h... yes

checking for stdint.h... yes

checking for unistd.h... yes

checking for long double... yes

checking size of long double... configure: error: cannot compute sizeof (long double), 77

See `config.log' for more details.

!!! ERROR: sys-libs/glibc-2.4-r3 failed.

Call stack:

  ebuild.sh, line 1546:   Called dyn_compile

  ebuild.sh, line 937:   Called src_compile

  glibc-2.4-r3.ebuild, line 1181:   Called src_compile

  glibc-2.4-r3.ebuild, line 1192:   Called toolchain-glibc_src_compile

  glibc-2.4-r3.ebuild, line 253:   Called glibc_do_configure 'nptl'

  glibc-2.4-r3.ebuild, line 943:   Called die

!!! failed to configure glibc

!!! If you need support, post the topmost build error, and the call stack if relevant.

```

edit : en regardant dans le config.log, j'ai vu que le /usr/lib32/libc.so posait le même problème : j'ai donc enlevé le AS_NEEDED du /usr/lib32/libc.so aussi et la glibc semble compiler  :Very Happy: 

Avant de me lancer dans le emerge -e world, pourrais-tu me dire si modifier le libc.so était une bonne idée (est-ce que c'est risqué, est-ce que ça peut faire échouer d'autres compilations...) ? Et merci de t'être intéressé à mon problème  :Very Happy: 

----------

## Mickael

peut-être un problème de toolchain. Raconte nous s'il te plaît depuis combien de temps cette gentoo est installée, ainsiq ue le type de mise à jour que tu faisais dessus. Tu t'es quand même bien mis dans la merde.

----------

## Mickael

 *Link31 wrote:*   

> Il y a un peu de progrès : j'ai enlevé "AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 )" du /usr/lib64/libc.so et maintenant j'arrive à compiler des helloworlds avec le 4.1.1.
> 
> Mais la Glibc ne passe toujours pas...
> 
>  *MickTux wrote:*   que retourne maintenant :
> ...

 

Est-ce une bonne idée : NON.

Mais c'est avant que l'on se pose ce genre de question.

Par exemple, un simple lien symbolique aurait peu-être résolu le problème (je dis cela en exemple). Ben maintenant que j'y pense ces deux commandes seraient pas mal (de toutes façons inoffencives) :

```
revdep-rebuild -pv
```

donne nous le résultat

puis on avisera avec le résultat de 

```
revdep-rebuild -v
```

EDIT : que dit le config.log, ne serait-il pas en train de parler de truc dans ce genre là :

```
/tools/bin/ld: warning: ld-linux.so.2, needed by /lib/libc.so.6, not found (try using -rpath or -rpath-link)

   /lib/libc.so.6: undefined reference to `_dl_lookup_versioned_symbol_skip at GLIBC_PRIVATE'

   /lib/libc.so.6: undefined reference to `_rtld_global at GLIBC_PRIVATE'

   /lib/libc.so.6: undefined reference to `_dl_lookup_versioned_symbol at GLIBC_PRIVATE'

   [...cut...]

   /lib/libc.so.6: undefined reference to `_dl_lookup_symbol at GLIBC_PRIVATE'

   /lib/libc.so.6: undefined reference to `_dl_map_object at GLIBC_PRIVATE'

   collect2: ld returned 1 exit status
```

Alors je miserais sur un lien symbolique comme ceci :

```
ln -s /lib/libc.so.6 /tools/lib/
```

EDIT 2 : regarde ce lien attention c'était l'époque de la 2005 :

http://dev.gentoo.org/~blubb/2005.0-upgrade-amd64.xml

On y retrouve ton problème.

Je suis curieux de connaître le résultat de emerge --info

----------

## Mickael

J'ai raison si je dis que tu es amd64 multilib?

----------

## Link31

 *MickTux wrote:*   

> peut-être un problème de toolchain. Raconte nous s'il te plaît depuis combien de temps cette gentoo est installée, ainsiq ue le type de mise à jour que tu faisais dessus. Tu t'es quand même bien mis dans la merde.

 

Elle date de mi-février 2006. Je la mets à jour très souvent, pas de souci de ce côté là. Et je suis en stable, mais avec un assez gros packages.keywords et quelques ebuilds dans packages.unmask. Un peu d'overlay aussi (notamment pour beryl & co).

J'ai aussi quelques trucs curieux, comme un revdep-rebuild impossible à corriger (ça date déjà d'un moment ça), mais je n'ai pas de problèmes particuliers avec les paquets concernés. J'ai aussi remarqué un comportement un peu bizarre de portage quand j'ai désinstallé koffice : l'ebuild s'est bien désinstallé mais koffice est encore là, fonctionne bien et s'est même lié tout seul (?) avec ma nouvelle version de KDE.

 *MickTux wrote:*   

> Est-ce une bonne idée : NON.
> 
> Mais c'est avant que l'on se pose ce genre de question.

 

 *Link31 wrote:*   

> Avant de me lancer dans le emerge -e world

 

Eh bien, je me la suis posée avant, pas de quoi s'énerver, hein ?  :Cool: 

 *MickTux wrote:*   

> Par exemple, un simple lien symbolique aurait peu-être résolu le problème (je dis cela en exemple). Ben maintenant que j'y pense ces deux commandes seraient pas mal (de toutes façons inoffencives) :
> 
> ```
> revdep-rebuild -pv
> ```
> ...

 

Comme je l'ai dit, revdep-rebuild me détecte des problèmes depuis longtemps, mais ça ne m'a jamais empêché de compiler :

```
...

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkresources.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkspell2.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkparts.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkutils.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkio.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkdesu.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkwalletclient.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkspell.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkdeui.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkdecore.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libDCOP.la)

  broken /usr/lib/libkspreadcommon.la (requires /usr/kde/3.4/lib64/libkdefx.la)

  broken /usr/lib/libkstore.la (requires /usr/kde/3.4/lib64/libkio.la)

  broken /usr/lib/libkstore.la (requires /usr/kde/3.4/lib64/libkdeui.la)

  broken /usr/lib/libkstore.la (requires /usr/kde/3.4/lib64/libkdesu.la)

  broken /usr/lib/libkstore.la (requires /usr/kde/3.4/lib64/libkwalletclient.la)

  broken /usr/lib/libkstore.la (requires /usr/kde/3.4/lib64/libkdecore.la)

  broken /usr/lib/libkstore.la (requires /usr/kde/3.4/lib64/libDCOP.la)

  broken /usr/lib/libkstore.la (requires /usr/kde/3.4/lib64/libkdefx.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libkabc.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libvcard.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libkresources.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libkdeprint.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libkparts.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libkio.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libkdeui.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libkdesu.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libkwalletclient.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libkdecore.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libDCOP.la)

  broken /usr/lib/libkudesignercore.la (requires /usr/kde/3.4/lib64/libkdefx.la)

  broken /usr/lib/libkugarlib.la (requires /usr/kde/3.4/lib64/libkdeprint.la)

  broken /usr/lib/libkugarlib.la (requires /usr/kde/3.4/lib64/libkparts.la)

  broken /usr/lib/libkugarlib.la (requires /usr/kde/3.4/lib64/libkio.la)

  broken /usr/lib/libkugarlib.la (requires /usr/kde/3.4/lib64/libkdeui.la)

  broken /usr/lib/libkugarlib.la (requires /usr/kde/3.4/lib64/libkdesu.la)

  broken /usr/lib/libkugarlib.la (requires /usr/kde/3.4/lib64/libkwalletclient.la)

  broken /usr/lib/libkugarlib.la (requires /usr/kde/3.4/lib64/libkdecore.la)

  broken /usr/lib/libkugarlib.la (requires /usr/kde/3.4/lib64/libDCOP.la)

  broken /usr/lib/libkugarlib.la (requires /usr/kde/3.4/lib64/libkdefx.la)

  broken /usr/lib/libkwmailmerge_interface.la (requires /usr/kde/3.4/lib64/libDCOP.la)

  broken /usr/lib/libkwmf.la (requires /usr/kde/3.4/lib64/libkdecore.la)

  broken /usr/lib/libkwmf.la (requires /usr/kde/3.4/lib64/libDCOP.la)

  broken /usr/lib/libkwmf.la (requires /usr/kde/3.4/lib64/libkdefx.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libkdeprint.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libkparts.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libkabc.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libvcard.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libkresources.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libkio.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libkdeui.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libkdesu.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libkwalletclient.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libkdecore.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libDCOP.la)

  broken /usr/lib/libkwordexportfilters.la (requires /usr/kde/3.4/lib64/libkdefx.la)

...
```

```
Dynamic linking on your system is consistent... All done.
```

Je précise que Koffice (que j'ai essayé en vain de désinstaller) fonctionne très bien...

 *MickTux wrote:*   

> EDIT : que dit le config.log, ne serait-il pas en train de parler de truc dans ce genre là :
> 
> Alors je miserais sur un lien symbolique comme ceci :
> 
> ```
> ...

 

Non, c'est (ou plutôt c'était, avant ma modification), des choses du genre :

```
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libc.so: file format not recognized; treating as linker script

/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libc.so:5: syntax error

collect2: ld a retourné 1 code d'état d'exécution
```

ou (après le source d'un programme de test produit par le configure) :

```
checking size of long double... configure: error: cannot compute sizeof (long double), 77 
```

edit :

En effet, je suis en multilib amd64 (multilib qui a parfaitement fonctionné jusqu'à aujourd'hui). Mais je n'ai jamais eu à faire la mise à jour vers le profil 2005.0 puisque j'ai installé une Gentoo 2005.1.

```
link31@linux ~$ emerge --info

Portage 2.1.1-r1 (default-linux/amd64/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.18-gentoo x86_64)

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

System uname: 2.6.18-gentoo x86_64 AMD Athlon(tm) 64 Processor 3500+

Gentoo Base System version 1.12.5

Last Sync: Sun, 29 Oct 2006 17:20:01 +0000

app-admin/eselect-compiler: [Not Present]

dev-java/java-config: [Not Present]

dev-lang/python:     2.3.5-r2, 2.4.3-r4

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     [Not Present]

dev-util/confcache:  [Not Present]

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.59-r7

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

sys-devel/binutils:  2.16.1-r3

sys-devel/gcc-config: 1.3.13-r4

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="amd64"

AUTOCLEAN="yes"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=k8 -pipe -O2"

CHOST="x86_64-pc-linux-gnu"

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

CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c"

CXXFLAGS="-march=k8 -pipe -O2"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"

GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"

LANG="fr_FR@euro"

LC_ALL="fr_FR@euro"

LINGUAS="fr en"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage /usr/local/layman/portage-xgl /usr/local/layman/science"

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

USE="amd64 X a52 aac acpi aim alsa apm arts audiofile bash-completion berkdb bitmap-fonts bzlib cdr cli cracklib crypt cups dlloader dri dvd dvdr eds elibc_glibc emboss encode esd ffmpeg foomaticdb fortran ftp gif gpm gstreamer gtk gtk+ gtk2 iconv icq imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog jpeg kde kernel_linux linguas_en linguas_fr lzw lzw-tiff mozilla mp3 mpeg msn ncurses nls nptl nptlonly ogg opengl oss pam pcre pdf perl png pppd python qt qt3 qt4 quicktime readline reflection sdl session spell spl ssl svg tcpd tiff truetype truetype-fonts type1-fonts usb userland_GNU video_cards_fbdev video_cards_nvidia video_cards_vesa videos vorbis xorg xpm xv xvid zlib"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
```

----------

## titoucha

 *MickTux wrote:*   

> peut-être un problème de toolchain. Raconte nous s'il te plaît depuis combien de temps cette gentoo est installée, ainsiq ue le type de mise à jour que tu faisais dessus. Tu t'es quand même bien mis dans la merde.

 

+1 je pense qu'un petit 

```
sh /usr/portage/scripts/bootstrap.sh
```

pour essayer de reconstruire la toolchain.

----------

## Link31

 *titoucha wrote:*   

> +1 je pense qu'un petit 
> 
> ```
> sh /usr/portage/scripts/bootstrap.sh
> ```
> ...

 

La compilation fonctionne maintenant, avec mes modifications dans /usr/lib{32,64}/libc.so. Est-ce que je dois quand même lancer le bootstrap ?

----------

## Mickael

 *Link31 wrote:*   

>  *titoucha wrote:*   +1 je pense qu'un petit 
> 
> ```
> sh /usr/portage/scripts/bootstrap.sh
> ```
> ...

 

Moi je le sens pas du tout ta modification.....si cela viens à planter pour ma part je crois que je serai perdu....

----------

## Link31

 *MickTux wrote:*   

> Moi je le sens pas du tout ta modification.....si cela viens à planter pour ma part je crois que je serai perdu....

 

De toute façon, sans elle, je ne peux rien compiler (bootstrap.sh ne fonctionne pas). Donc je la laisse, je lance le bootstrap.sh et on verra si mes modifications sont annulées...

----------

## Mickael

Pendant que tu compiles est-ce que tu as lib32 dans /etc/env.d/04multilib, un truc du genre :

```
LDPATH="/lib:/usr/lib:/usr/local/lib:/lib64:/lib32:/usr/lib64:/usr/local/lib64"
```

Si il n'y est pas je crois qu'il suffisait d'éditer ce fichier puis d'y insérer lib32 et cela aurait de nouveau fonctionner.

----------

## Link31

On dirait que ça vient de binutils (http://sourceware.org/ml/libc-alpha/2005-03/msg00208.html). Apparemment Glibc 2.4 ajouterait le AS_NEEDED, mais il faudrait un ld >= 2.16 pour le comprendre.

Est-ce que je peux interrompre le bootstrap.sh pour installer binutils 2.17 et voir si ça fonctionne ?

edit : faudra-t-il recompiler gcc, glibc... après avoir changé les binutils et rétabli le fichier /usr/lib64/libc.so que j'avais modifié (en supposant que ça fonctionne) ?Last edited by Link31 on Mon Oct 30, 2006 4:43 pm; edited 2 times in total

----------

## Mickael

Attends la fin maintenant. 

Ce lien est également très intéressant.

EDIT : réponse à ton édit : avec le emerge -e system qui va suivre gcc et glibc seront de nouveau compilés.

----------

## Link31

Bon, ça venait bien des binutils. Mais pourquoi les binutils 2.17 n'ont-t-ils pas été installés automatiquement par portage en même temps que la glibc 2.4, alors qu'ils sont nécessaires ? Et pourquoi ce problème ne semble être arrivé qu'à moi ?!

----------

## Mickael

non, pas qu'à toi, ils sont nombreux dans le forum dédié à amd64. Mais si c'est résolu peux tu éditer ton titre en conséquence stp. Décrit également ici, comment tu as résolu ton problème. Merci  :Wink: 

----------

## Link31

 *MickTux wrote:*   

> Mais si c'est résolu peut éditer ton titre en conséquence stp.

 

Euh, pour le résolu, je préfère attendre que tout soit bien recompilé. On n'est jamais à l'abri de problèmes supplémentaires. Et le sujet était la migration de GCC, pas la Glibc ou les Binutils.

 *MickTux wrote:*   

> Décrit également ici, comment tu as résolu ton problème. Merci 

 

Bah je pensais que c'était assez clair :

- après la mise à jour de la glibc, j'avais un message d'erreur concernant /usr/lib64/libc.so : "traité comme un script" puis "erreur de syntaxe"

- pour le résoudre, il faut mettre à jour les binutils au moins à la version 2.17 (actuellement en ~amd64)

- ne pas oublier de lancer binutils-config pour sélectionner les nouveaux binutils.

----------

## Mickael

Certes c'est clair pout toi et moi qui avons suivis ce thread, mais figure toi que tout le monde ne percute pas à la même vitesse, un petit rappel c'est bien plus clair, plus lisible. Imagine que ton post s'éternise sur 10 pages.... tu imagines que le premier poste avec un update des améliorations effectuées tout au long de ces 10 pages ça aide pas mal.

----------

## kopp

TOn glibc est en ~amd64 ou simplement amd64 ? Si c'est le deuxieme cas, c'est sérieusement broken tout ça. Si c'est le premier, il faut voir si un rapport de bogue a été fait, sinon en faire un.

----------

## Link31

 *kopp wrote:*   

> TOn glibc est en ~amd64 ou simplement amd64 ? Si c'est le deuxieme cas, c'est sérieusement broken tout ça. Si c'est le premier, il faut voir si un rapport de bogue a été fait, sinon en faire un.

 

C'est la Glibc 2.4-r3, en amd64 (donc stable). En fait je l'avais masquée depuis un moment parce que j'avais entendu dire qu'elle ne compilait qu'avec GCC4. Je l'ai démasquée en même temps que j'ai mis à jour le GCC.

Par contre, les Binutils 2.17 sont en ~amd64. Ça m'étonne, parce qu'on dirait qu'ils sont requis à partir de la Glibc 2.4...

----------

## Mickael

Tout comme kopp, je crois qu'un rapport de bug s'impose. En tout cas chapeau bas pour avoir régler ce problème, je crois qu'il servira à plus d'un.

----------

## Link31

Oui, pourquoi pas. Mais je n'ai pas l'habitude de ce genre de choses, et mon anglais (écrit) n'est peut-être pas suffisant...

Si quelqu'un veut bien s'en charger, je précise que mon emerge --info et le contenu de /usr/lib64/libc.so sont dans la page précédente. Je peux aussi donner toutes les infos nécessaires supplémentaires.

 *MickTux wrote:*   

> En tout cas chapeau bas pour avoir régler ce problème, je crois qu'il servira à plus d'un.

 

Merci, mais est-ce que la méthode ne serait pas mieux ailleurs qu'au fond de ce fil ? On peut la mettre sur le bugzilla, mais ça pourrait être utile de l'indiquer dans le sous-forum documentation et astuces, non ?

----------

## Mickael

 *Link31 wrote:*   

> 
> 
>  *MickTux wrote:*   En tout cas chapeau bas pour avoir régler ce problème, je crois qu'il servira à plus d'un. 
> 
> Merci, mais est-ce que la méthode ne serait pas mieux ailleurs qu'on fond de ce fil ? On peut la mettre sur le bugzilla, mais ça pourrait être utile de l'indiquer dans le sous-forum documentation et astuces, non ?

 

Là je laisse cette réflexion aux modos.

----------

## titoucha

 *Link31 wrote:*   

>  *kopp wrote:*   TOn glibc est en ~amd64 ou simplement amd64 ? Si c'est le deuxieme cas, c'est sérieusement broken tout ça. Si c'est le premier, il faut voir si un rapport de bogue a été fait, sinon en faire un. 
> 
> C'est la Glibc 2.4-r3, en amd64 (donc stable). En fait je l'avais masquée depuis un moment parce que j'avais entendu dire qu'elle ne compilait qu'avec GCC4. Je l'ai démasquée en même temps que j'ai mis à jour le GCC.
> 
> Par contre, les Binutils 2.17 sont en ~amd64. Ça m'étonne, parce qu'on dirait qu'ils sont requis à partir de la Glibc 2.4...

 

Je suis très étonné, car mon système en amd64 fonctionne et conpile parfaitement avec la Glibc-2.4.3-r3 et Binutils-2.16.1-r3 et je n'ai rien dû modifier comme tu l'as fait.

----------

## Mickael

Juste une remarque link31, tu pourras faire le ménage de python avec /usr/sbin/python-updater. Ton emerge --info indique la présence de deux versions de python sur ta machine.

----------

## Link31

 *titoucha wrote:*   

> Je suis très étonné, car mon système en amd64 fonctionne et conpile parfaitement avec la Glibc-2.4.3-r3 et Binutils-2.16.1-r3 et je n'ai rien dû modifier comme tu l'as fait.

 

Ah, il me semblait bien que c'était un problème qui n'est arrivé qu'à moi, d'autant plus qu'il n'y avait rien sur le bugzilla au sujet de la glibc...

Peut-être que ça vient de là :

```
link31@linux ~ $ genlop -s binutils

 * matches found:

     Mon Mar 13 21:00:53 2006 >>> sys-devel/binutils-config-1.8-r6

     Mon Mar 13 21:04:07 2006 >>> sys-devel/binutils-2.16.1

     Thu May 25 15:49:31 2006 >>> sys-devel/binutils-config-1.8-r7

     Sat May 27 15:14:58 2006 >>> sys-devel/binutils-2.16.1-r2

     Sun Jul  2 17:03:58 2006 >>> sys-devel/binutils-2.16.1-r3

     Thu Oct  5 20:56:28 2006 >>> sys-devel/binutils-config-1.9-r2

     Mon Oct 30 16:42:16 2006 >>> sys-devel/binutils-2.16.1-r3

     Mon Oct 30 18:52:08 2006 >>> sys-devel/binutils-2.17

     Mon Oct 30 21:57:34 2006 >>> sys-devel/binutils-2.17

     Mon Oct 30 22:54:25 2006 >>> sys-devel/binutils-config-1.9-r2

link31@linux ~ $ binutils-config -l

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

 [2] x86_64-pc-linux-gnu-2.17 *

```

Je peux choisir entre les binutils 2.15.92 (?) et les binutils 2.17, alors que je n'ai jamais installé les 2.15.92 mais les 2.16.1 !

Peut-être que les 2.15.92 ont toujours été présents, et que je n'avais pas utilisé binutils-config pour choisir les 2.16 quand je les ai installés. Ce qui expliquerait que j'avais des problèmes avec le /usr/lib64/libc.so qui requérait les 2.16 au moins.

Enfin, c'est impossible de vérifier maintenant, sauf peut-être en chrootant ma sauvegarde... Une question : l'ebuild des binutils ne devrait-il pas effectuer le changement tout seul en utilisant binutils-config, comme le fait par exemple l'ebuild des drivers nvidia ?

@MickTux : tu penses que je devrais lancer ce script, malgré le emerge -e world ? (je me suis déjà fait avoir avec le script perl qui voulait reconstruire des paquets que j'étais déjà en train de reconstruire avec le emerge -e world)

----------

## titoucha

 *Link31 wrote:*   

> Enfin, c'est impossible de vérifier maintenant, sauf peut-être en chrootant ma sauvegarde... Une question : l'ebuild des binutils ne devrait-il pas effectuer le changement tout seul en utilisant binutils-config, comme le fait par exemple l'ebuild des drivers nvidia ?

 

Comme tu le dit c'est normalement automatique, en tout cas je ne l'ai jamais fait.

----------

## Mickael

 *Quote:*   

> @MickTux : tu penses que je devrais lancer ce script, malgré le emerge -e world ? (je me suis déjà fait avoir avec le script perl qui voulait reconstruire des paquets que j'étais déjà en train de reconstruire avec le emerge -e world)

 

Attends la fin maintenant, tu le feras après.

----------

## titoucha

Il devra quand même refaire un emerge -e system car le script rajoute des flags internes qu'il faut ensuite supprimer.

----------

## Mickael

Je comprends pas trop là, un passage à une version supérieure de python impose un eptit nettoyage : python-updater. Et ce script impose un emerge-e system  :Confused:   Je suis au ralenti en ce moment avec ma grippe alors tappe pas trop fort petit chat.  :Laughing: 

----------

## Link31

 *titoucha wrote:*   

> Il devra quand même refaire un emerge -e system car le script rajoute des flags internes qu'il faut ensuite supprimer.

 

Ho, du calme, le python-updater ne veut réémerger que la libcap, pas besoin de recompiler tout le system quand même... Et puis je commence à en avoir un peu marre des emerge --emptytree  :Laughing: 

Bon, en tout cas le emerge -e world + noyau s'est bien passé, tout fonctionne après un reboot. Il me reste quelques gros programmes KDE que je recompilerai plus tard. J'ai aussi sauté Inkscape, Firefox et OpenOffice.org, mais apparemment le nouveau GCC n'a pas trop l'air de les gêner. Est-ce vraiment utile (hors optimisations) de les recompiler si tout fonctionne ?

Quoi qu'il en soit... => [résolu]

----------

## titoucha

 *MickTux wrote:*   

> Je comprends pas trop là, un passage à une version supérieure de python impose un eptit nettoyage : python-updater. Et ce script impose un emerge-e system   Je suis au ralenti en ce moment avec ma grippe alors tappe pas trop fort petit chat. 

 

@MickTux je crois qu'on ne sait pas compris je parlais du scirpt /usr/portage/scripts/bootstrap.sh car il te demandait sil devait lancer quand même bootstrap, en fait tu as la grippe et c'est moi qui délire, tu as le droit de taper, mais pas fort  :Embarassed: 

----------

