OVH Cloud OVH Cloud

utilisateur decu

69 réponses
Avatar
du64
au debut aucun probleme avec la gentoo mais maintenant c'est souvent ca:
/usr/lib/libGL.so: undefined reference to `_nv000793gl'
/usr/lib/libGL.so: undefined reference to `_nv000795gl'
/usr/lib/libGL.so: undefined reference to `_nv000792gl'
/usr/lib/libGL.so: undefined reference to `_nv000797gl'
/usr/lib/libGL.so: undefined reference to `_nv000794gl'
/usr/lib/libGL.so: undefined reference to `_nv000800gl'
/usr/lib/libGL.so: undefined reference to `_nv000798gl'
/usr/lib/libGLcore.so.1: undefined reference to `_nv000790gl'
/usr/lib/libGL.so: undefined reference to `_nv000796gl'
/usr/lib/libGL.so: undefined reference to `_nv000791gl'
/usr/lib/libGL.so: undefined reference to `_nv000799gl'
/usr/lib/libGL.so: undefined reference to `_nv000801gl'
collect2: ld returned 1 exit status
make[1]: *** [glmovie] Error 1
make[1]: Leaving directory
`/var/tmp/portage/smpeg-0.4.4-r5/work/smpeg-0.4.4'
make: *** [all-recursive] Error 1

!!! ERROR: media-libs/smpeg-0.4.4-r5 failed.
!!! Function src_compile, Line 47, Exitcode 2
!!! emake failed
!!! If you need support, post the topmost build error, NOT this status
message.

10 réponses

1 2 3 4 5
Avatar
Jerome Lambert
Michel Talon wrote:
Jerome Lambert wrote:

Bah, chez moi sur un P-3 450 ça n'a pas duré trop longtemps (plus quand
même que sur mon Athlon64 3000+), mais quel plaisir d'y arriver ;-)

Prochaine étape: acheter un disque externe FireWire pour mon iMac G5 et
y installer une Gentoo PPC, mais ce sera "quand j'aurai le temps"...



Sincèrement je ne connais pas la Gentoo ni si son administration est facile,


C'est pour moi *le* point névralgique: l'administration passe par des
outils clairs et des fichiers correctement documentés, et l'arborescence
de /etc est *très* claire, et à mon sens plus claire que Debian.

mais je n'arrive pas à comprendre pourquoi vous vous escrimez à recompiler
le système. Ils doivent bien fournir un système pré-compilé quand même,
sur lequel on peut tourner "faute de mieux". Je te mets au défi de prouver
chiffres à l'appui que l'OS ira "plus vite" si tu le compiles mieux, avec
de meilleurs optimisations plus adaptées à la machine. Moi qui fais du calcul
scientifique, je peux t'assurer qu'il y a de nombreux programmes qui tournent
plus vite compilés avec -O que avec -O2 ou -O3. C'est programme par programme
qu'il faut choisir les options de compilation. De toute façon sur un OS où
la quasi totalité du temps se passe à converser avec des périphériques, toute
différence de temps liée au choix des instructions processeur n'est pas
mesurable. L'un des rares codes de l'OS qu'il faut soigner c'est le code qui
fournit des blocs remplis de zéros, et en général ce code est écrit en
assembleur et utilise directement les instructions adaptées à la machine.


Pour les optimisations, effectivement O2 ou O3 ne change pas
fondamentalement la donne (j'en reste souvent à O2 qui est le choix par
défaut). Par contre Os fait des merveilles sur des machines à la
configuration limitée.

Par contre recompiler mplayer pour l'optimiser, évidemment d'accord.


C'est également un point à mettre à son crédit: on peut recompiler les
applications en fonction de la configuration tant matérielle (et activer
p.ex. SSE ou Altivec pour les applis qui le supportent) que logicielles
(et activer le "support" Gnome des applis qui le supporte).

L'avantage justement de Gentoo sur p.ex. Slackware est que l'on définit
une fois pour toutes les optimisations voulues, et les paquets seront
compilés suivants les options reconnues, au lieu de tout se palucher
paquet par paquet.

Tout cela donne une distribution sur mesure et parfaitement adaptée au
matériel sur lequel elle tourne.

Si FreeBSD pousse à recompiler le système pour les upgrades, c'est pour des
raisons de commodité, parceque c'est trés facile d'upgrader comme ça, et
que ça prend de 1/2 heure à 1 heure selon la machine, mais certainement pas
pour des raisons de performance.


Personnellement, le critère "performance" n'est pas déterminant, au
contraire de la facilité d'administration et de l'adaptation aux choix
de l'administrateur.


Avatar
Irvin Probst
On 2005-04-02, Jerome Lambert wrote:

C'est pour moi *le* point névralgique: l'administration passe par des
outils clairs et des fichiers correctement documentés, et l'arborescence
de /etc est *très* claire, et à mon sens plus claire que Debian.


Arguments ?

--
Irvin

Avatar
Ronald
Le Sat, 02 Apr 2005 23:49:33 +0200, Jerome Lambert a écrit :

L'avantage justement de Gentoo sur p.ex. Slackware est que l'on définit
une fois pour toutes les optimisations voulues, et les paquets seront
compilés suivants les options reconnues, au lieu de tout se palucher
paquet par paquet.


essayes de rajouter un -m128bit-long-double aux CFLAGS pour voir si tu
peux raisonnablement balancer des optimisations génériques pour toutes
les applications.

Avatar
Jerome Lambert
Irvin Probst wrote:
On 2005-04-02, Jerome Lambert wrote:

C'est pour moi *le* point névralgique: l'administration passe par des
outils clairs et des fichiers correctement documentés, et l'arborescence
de /etc est *très* claire, et à mon sens plus claire que Debian.



Arguments ?


De tête:
- /etc/conf.d/ p.ex. (regroupement des fichiers de configuration système)?
- Un fichier de conf par interface réseau?
- portage plus pratique que apt-get car regroupement thématique des paquets?

Mais en creusant en peu, je devrais encore en trouver, mais ici à la
maison j'ai des Debian et mes machines Gentoo sont au boulot...


Avatar
Nicolas George
Jerome Lambert , dans le message , a
écrit :
Par contre Os fait des merveilles sur des machines à la
configuration limitée.


Je n'y crois pas, c'est négligeable par rapport à l'utilisation dynamique de
mémoire d'une application typique.

Avatar
Jerome Lambert
Nicolas George wrote:
Jerome Lambert , dans le message , a

Par contre Os fait des merveilles sur des machines à la
configuration limitée.



Je n'y crois pas, c'est négligeable par rapport à l'utilisation dynamique de
mémoire d'une application typique.


On a déja eu cette discussion. Essaye et tu verras, c'est tout ce que je
peux te dire...


Avatar
talon
Jerome Lambert wrote:


Sincèrement je ne connais pas la Gentoo ni si son administration est facile,


C'est pour moi *le* point névralgique: l'administration passe par des
outils clairs et des fichiers correctement documentés, et l'arborescence
de /etc est *très* claire, et à mon sens plus claire que Debian.


Pas difficile, à mon avis le /etc de Debian est quasi obscène par rapport à ce
à quoi je suis habitué (FreeBSD). Evidemment ce n'est pas aussi moche que
Mandrake ou des trucs du genre, qui sont des insultes à la face du soleil,
mais c'est du Linux typique ...


Pour les optimisations, effectivement O2 ou O3 ne change pas
fondamentalement la donne (j'en reste souvent à O2 qui est le choix par
défaut). Par contre Os fait des merveilles sur des machines à la
configuration limitée.


C'est possible, il y a longtemps que je n'ai plus de machine comme ça.


Personnellement, le critère "performance" n'est pas déterminant, au
contraire de la facilité d'administration et de l'adaptation aux choix
de l'administrateur.


Bien d'accord, étant entendu que selon les cas les performances doivent varier
de 1 ou 2% dans un sens ou l'autre. Evidemment s'il s'agissait de 30% ce
serait différent.


--

Michel TALON


Avatar
l'indien
On Sun, 03 Apr 2005 00:34:51 +0200, Jerome Lambert wrote:

Nicolas George wrote:
Jerome Lambert , dans le message , a

Par contre Os fait des merveilles sur des machines à la
configuration limitée.



Je n'y crois pas, c'est négligeable par rapport à l'utilisation dynamique de
mémoire d'une application typique.


On a déja eu cette discussion. Essaye et tu verras, c'est tout ce que je
peux te dire...


Quand on utilise des architectures embedded, surtout avec une mémoire
limitée, compiler avec autre chose que -Os peut se réveler vite
catastrophique... Dans l'exemple que je donnais, je précise que je n'ai
compilé la Gentoo que pour voir si c'était possible (réponse: oui) mais
c'est de toute façon inutilisable car rien que la libc mange 10 à 15 %
de la RAM...
Par contre, pour avoir pas mal travaillé sur les flags de compil sur ce
genre d'architecture, je peux affirmer qu'entre un système bien compilé
et un compilé avec les flags génériques (c.a.d juste -O2), on arrive à
des rapports de performances de 2 à 10 suivant les cas.

Bien évidement, sur un P IV qui passe son temps à ne rien faire, les
goulots d'étranglements sont liés au matériel (on ne peut pas
accéléler, ou très peu, le chargement de ce qui vient du disque) donc
on ne voit pas bien la différence entre un soft compilé n'importe
comment et un optimisé....



Avatar
GP
Michel Talon wrote:
Jerome Lambert wrote:

Bah, chez moi sur un P-3 450 ça n'a pas duré trop longtemps (plus quand
même que sur mon Athlon64 3000+), mais quel plaisir d'y arriver ;-)

Prochaine étape: acheter un disque externe FireWire pour mon iMac G5 et
y installer une Gentoo PPC, mais ce sera "quand j'aurai le temps"...



Sincèrement je ne connais pas la Gentoo ni si son administration est facile,
mais je n'arrive pas à comprendre pourquoi vous vous escrimez à recompiler
le système. Ils doivent bien fournir un système pré-compilé quand même,
sur lequel on peut tourner "faute de mieux". Je te mets au défi de prouver
chiffres à l'appui que l'OS ira "plus vite" si tu le compiles mieux


Ah mais, ce n'est pas du tout la question, mon cher Chichille. Tu fais encore
exprès pour ne rien comprendre?

Selon ce qu'on m'a expliqué dernièrement, tout est dans les FLAGs. Sans FLAGs,
point de salut sur Linux. Il paraît que si tu compiles mpalyer sans les flags,
par exemple, il risque de ne pas voir Xvid, tandis que si tu mets le flag, il
le voit tout de suite. J'en suis à me demander comment mon système fait pout
fonctionner sans tous ces FLAGs. Il a vraiment beaucoup de mérite.

C'est pourquoi je pense passer bientôt à Gentoo. Et puis, ce qui est chouette,
c'est que, une fois que tu roules Gentoo, tu n'as plus à te préoccuper te
rien: bichonner ton OS absorbe toute ton attention. La mort du pape, le procès
de Michael Jackson, Wolfo à la Banque monduale, tout ça, ça ne te préoccupe
plus. Même les boules de Pam... Hein? Bon d'accord, toi, ça pourrait encore te
t'occuper.

Je rêve de Gentoo! Pourquoi faire simple quand on peut faire compliqué?

GP


Avatar
l'indien
On Sat, 02 Apr 2005 21:20:15 +0000, Michel Talon wrote:

Jerome Lambert wrote:

Bah, chez moi sur un P-3 450 ça n'a pas duré trop longtemps (plus quand
même que sur mon Athlon64 3000+), mais quel plaisir d'y arriver ;-)

Prochaine étape: acheter un disque externe FireWire pour mon iMac G5 et
y installer une Gentoo PPC, mais ce sera "quand j'aurai le temps"...


Sincèrement je ne connais pas la Gentoo ni si son administration est facile,
mais je n'arrive pas à comprendre pourquoi vous vous escrimez à recompiler
le système. Ils doivent bien fournir un système pré-compilé quand même,
sur lequel on peut tourner "faute de mieux". Je te mets au défi de prouver
chiffres à l'appui que l'OS ira "plus vite" si tu le compiles mieux, avec
de meilleurs optimisations plus adaptées à la machine. Moi qui fais du calcul
scientifique, je peux t'assurer qu'il y a de nombreux programmes qui tournent
plus vite compilés avec -O que avec -O2 ou -O3.


Il faut bien les choisir, les programmes qui tournent mieux sans
optimisation... Quand tu compares les codes générés, ce n'est pas du
tout crédible pour 90 % des programmes...

C'est programme par programme
qu'il faut choisir les options de compilation. De toute façon sur un OS où
la quasi totalité du temps se passe à converser avec des périphériques,


Si ton OS passe la majorité de son temps en attente d'I/O, soit tu
travailles uniquement avec des disques réseaux, soit tu as un gros
problème matériel. Le temps passé en attente d'I/O dépasse rarement
les 10% du temps CPU. Si tu fais du profiling, tu verras que pour la très
grande majorité des programmes, ce n'est pas dans les syscalls que le
temps est perdu.
Sauf, évidement, si le programme ne fait qu'une boucle d'attente sur un
select....


toute
différence de temps liée au choix des instructions processeur n'est pas
mesurable.


Hum. C'est la base du profiling et c'est pourtant très efficace. On
mesure au cycle près le temps passé dans les différentes parties pour
savoir quoi optimiser. Et les résultats démontrent la validité des
optimisations de gcc, dans la plupart des cas. Il y a aussi des cas ou
les bugs d'optimisation de gcc lui font générer du code, certes correct,
mais 2 à 3 fois plus long que le code le plus rapide, mais c'est
heureusement loin d'être un constat général...

L'un des rares codes de l'OS qu'il faut soigner c'est le code qui
fournit des blocs remplis de zéros, et en général ce code est écrit en
assembleur et utilise directement les instructions adaptées à la machine.


Si tu n'optimises que ça (et si Linux n'optimisait que celà...) dans
l'OS, effectivement, ce n'est pas la peine d'essayer d'optimiser les
applications: quand le noyau ne marche pas efficacement, on ne peut rien
faire au niveau user...

Si FreeBSD pousse à recompiler le système pour les upgrades, c'est
pour des raisons de commodité, parceque c'est trés facile d'upgrader
comme ça, et que ça prend de 1/2 heure à 1 heure selon la machine,
mais certainement pas pour des raisons de performance.


Et bien, tu pourrais au moins garder cet argument pourla gentoo, non ?
Et puis, si tu n'est pas convaincu, fait l'essai: compile 2 Gentoo, l'une
entièrement en -O, l'autre avec des optimisations correctes et compare
ensuite le temps de boot, la consomation mémoire, etc..., tu risque
d'avoir quelques surprises, je pense.


1 2 3 4 5