On Sat, 15 Sep 2007 12:23:30 +0200
"Richard Gill" <[EMAIL PROTECTED]> wrote:

> L'origine de cette discussion vient du fait que l'équipe de gcc a
> modifié son système de construction entre la 4.1.x et la 4.2.x,
> rendant le book LFS obsolète avec cette version.
> Par ailleurs, l'équipe de dev de glibc a modifié quelques
> caractéristiques essentielles du système sur lequel est est utilisée,
> c'est à dire qu'elle doit être compilée au minimum pour une
> architecture i486 à partir de la 2.6.x, ...
> Un dev de LFS a fait une branche, qui tentait d'intégrer ces deux
> changements, tout en permettant une compilation x86_64, qui devient
> aussi diffusable que du x86 ...
> 
> Je ne vais pas décrire le coeur des discussions, mais faire une courte
> synthèse des propositions qui semblent aller dans la bonne direction:
> 
> avoir un CC qui indique l'architecture:
> CC='gcc -march=i686'
> (ou plutôt $NC_HOST_CPU, et on peut déjà penser à mettre gcc
> -march=x86_64 pour disposer du support 64bits)
> fournir des options de compilation par défaut qui n'indiquent pas
> l'architecture:
> CFLAGS='-s -O3 -pipe'
> CXXFLAGS="$CFLAGS -Wno-deprecated"
> 
> Notez qu'il y a des choses à vérifier:
> - certains paquets mal foutu nutilisent pas la variable
> d'environnement CC, mais directement le nom du compilo, il faudra
> modifier les fichiers de config de ces paquets avant de compiler
> - pour le support du x86 depuis un hôte 64bits, et voire plus tard, le
> support de la cross-compil, il serait judicieux de commencer à
> intégrer des paramètres supplémentaires au ./configure pour indiquer
> la plateforme hote, la plateforme de build et la plateforme cible)

Si je comprends bien les évolutions gcc / glibc, on s'oriente vers plus de 
souplesse, ce qui demandera plus de rigueur également :p

Pour m'affranchir des problèmes dûs à l'hôte x86_64 j'ai installé Virtualbox et 
testé une 32 bits dedans. Ca marche bien, la prochaine étape est d'y tester 
Ncooker.


+
fraazz.

-- 
[0x366720B7]

_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev

Répondre à