1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
|
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/base/amd64/install-software.xml,v 1.1 2005/01/22 16:00:33 cam Exp $ -->
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The context of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommonds.org/licenses/by-sa/1.0 -->
<sections>
<section>
<title>Noyaux disponibles</title>
<subsection>
<title>Sur le LiveCD</title>
<body>
<p>
Pour ce qui est de la version 2004.3, le LiveCD contient un noyau sur lequel
vous pouvez démarrer. Ce noyau s'appelle <c>gentoo</c> et supporte le SMP. Cela
dit, les machines monoprocesseurs peuvent également l'utiliser.
</p>
</body>
</subsection>
<subsection>
<title>Utiliser les bonnes sources de noyau</title>
<body>
<impo>
Utilisez la série de noyaux <path>sys-kernel/gentoo-dev-sources</path> !
Elle contient des correctifs spécifiques aux AMD64, ainsi qu'un certain nombre
d'améliorations supplémentaires. Nous ne pourrons pas vous aider si vous
utilisez d'autres sources.
</impo>
</body>
</subsection>
<subsection>
<title>Construire un noyau pour un portable eMachine</title>
<body>
<p>
Quand vous configurez le noyau pour être utilisé sur un portable Athlon64 Mobile
de type eMachine, vous <e>devez</e> compiler le support USB dans le noyau et non
en module. Si vous ne le faites pas, vous aurez des erreurs de type
« unknown keypress » de la part de <path>atkbd.c</path>. Désactiver le
support USB ne fonctionnera pas.
</p>
<p>
Les rapports de bon ou mauvais fonctionnement de ces portables sur la version
2004.3 sont à soumettre sur le <uri link="http://bugs.gentoo.org">bugzilla de
Gentoo</uri>.
</p>
</body>
</subsection>
<subsection>
<title>Les noyaux 2.4.x officiellement désuets</title>
<body>
<p>
<b>La série des noyaux 2.4.x est officiellement déclarée désuète pour les
AMD64.</b> Depuis le 2.4.23-pre7, devfs a été désactivé (en dur dans le noyau),
car il était la cause de corruption de mémoire. Chez Gentoo, nous n'avons pas
remarqué de tels problèmes, mais les 2.4 ne sont de toute façon pas une bonne
solution sur Gentoo sans le devfs.
</p>
</body>
</subsection>
<subsection>
<title>gcc 3.3 officiellement désuet</title>
<body>
<p>
<b>gcc3.3 est officiellement désuet pour les AMD64, depuis la sortie de Gentoo
2004.3.</b> Tous les supports de la 2004.3 sont basés sur gcc 3.4.x.
</p>
</body>
</subsection>
</section>
<section>
<title>Kernel Panic au démarrage</title>
<body>
<p>
Si vous avez des « Kernel Panic » au démarrage, essayez d'utiliser le
paramètre <c>idle=poll</c> dans les options de démarrage. Il y a un problème
avec plusieurs BIOS et il semble que cela touche principalement les cartes mères
à chipset VIA. Vous ne devez essayer de passer cette option au démarrage
qu'<e>après</e> avoir mis à jour votre BIOS vers la dernière version disponible
de votre constructeur de carte mère. Vous devriez également pouvoir résoudre ce
problème en désactivant le support USB au démarrage dans votre BIOS. Si vous
êtes obligé de mettre l'option <c>idle=poll</c>, merci de contacter votre
constructeur de carte mère ou fournisseur de BIOS pour qu'il corrige le BIOS sur
l'erreur de CPU N°93 (CPU Errata #93).
</p>
<p>
Pour plus d'information sur ce point, vous pouvez consulter les archives des
listes de diffusion suivantes :
</p>
<ul>
<li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0031.html</uri></li>
<li><uri>http://lists.suse.com/archive/suse-amd64/2003-Dec/0034.html</uri></li>
</ul>
<p>
Vous remarquerez que ce n'est pas un problème spécifique à Gentoo !
</p>
</body>
</section>
<section>
<title>Support des systèmes de fichiers</title>
<body>
<p>
Nous vous recommandons actuellement d'utiliser les formats ext2/3. Nous avons
des rapports qui indiquent des problèmes aléatoires avec le reiserfs sur AMD64
et avons entendu parler de problèmes majeurs avec le JFS sur des systèmes
64 bits (ce qui semble réellement étrange, dans la mesure où le JFS a été
initialement conçu pour des systèmes 64 bits).
</p>
<table>
<tr>
<th>Système de fichiers</th>
<th>Statut</th>
</tr>
<tr>
<ti>ext2</ti>
<ti>STABLE</ti>
</tr>
<tr>
<ti>ext3</ti>
<ti>STABLE</ti>
</tr>
<tr>
<ti>XFS</ti>
<ti>STABLE, >=gentoo-dev-sources-2.6.3</ti>
</tr>
<tr>
<ti>JFS</ti>
<ti>STABLE, >=gentoo-dev-sources-2.6.7</ti>
</tr>
<tr>
<ti>reiserfs</ti>
<ti>STABLE, >=gentoo-dev-sources-2.6.5</ti>
</tr>
<tr>
<ti>reiser4</ti>
<ti>NE FONCTIONNE PAS SUR AMD64, N'EST SUPPORTÉ SUR AUCUNE ARCHITECTURE !</ti>
</tr>
</table>
<p>
Merci de nous rapporter tous les problèmes rencontrés avec vos systèmes de
fichiers sur <uri link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
</p>
</body>
</section>
<section>
<title>Le gestionnaire de démarrage : Compilation de grub</title>
<body>
<p>
Grub ne se compile pas dans un environnement 64 bits pur. Il ne pourra être
compilé qu'en utilisant gcc avec le support multilib. Gentoo 2004.3 inclut le
support multilib par défaut. Si vous choisissez de supprimer le support
multilib pour gcc, alors vous devrez utiliser <c>grub-static</c>.
<c>grub-static</c> peut être installé en utilisant les commandes
suivantes :
</p>
<pre>
# <i>emerge grub-static</i>
# <i>cp -Rpv /usr/share/grub/i386-pc/* /boot/grub</i>
</pre>
</body>
</section>
<section>
<title>Certains paquets sont toujours masqués</title>
<body>
<p>
Certains paquets marqués stables sur d'autres architectures sont toujours
masqués sur AMD64. Cela ne signifie pas forcément qu'ils ne fonctionnent pas,
mais que, simplement, aucun développeur Gentoo n'a pu les tester sur une machine
AMD64. Si vous le pouvez, merci de tester ces applications masquées et de <uri
link="http://bugs.gentoo.org">soumettre un rapport de bogue</uri> pour informer
les développeurs que le paquet fonctionne ou pas.
</p>
</body>
</section>
<section>
<title>Les paquets qui ne fonctionnent pas</title>
<body>
<p>
Ne fonctionnent actuellement pas :
</p>
<ul>
<li>Firebird (la base de données, PAS le navigateur).</li>
</ul>
<p>
Les applications qui ne fonctionnent pas en mode 64 bits, mais qui
fonctionnent en mode 32 bits, en supposant que
app-emulation/emul-linux-x86-baselibs et compagnie soient installés :
</p>
<ul>
<li>
Tout programme qui utilise des DLL 32 bits qui viennent de Windows (comme
le support de mplayer/xine pour certains formats propriétaires).
</li>
<li>
Tous les programmes qui nécessitent un code assembleur en 32 bits.
</li>
</ul>
</body>
</section>
<section>
<title>Le support de Java</title>
<body>
<p>
Blackdown a sorti une version de Java pour Linux sur AMD64 en 64 bits
natif. C'est une candidate de sortie donc n'espérez pas qu'elle soit parfaite.
Elle se trouve dans Portage en tant que <path>blackdown-jdk-1.4.2</path> et
<path>blackdown-jre-1.4.2</path>.
</p>
<p>
Certaines personnes ont remarqué que la machine virtuelle Java 64 bits est
plus lente que la version 32 bits. Juergen Kreileder, du projet Blackdown,
a apporté une réponse à cette remarque :
</p>
<pre>
Actuellement, la machine virtuelle 64 bits est plus rapide que la
32 bits dans la plupart des tests effectués.
La différence que ces personnes ont remarqué doit probablement
provenir de l'utilisation de machines virtuelles différentes :
La version i386 est fournie avec le client de machine virtuelle
HotSpot et le serveur HotSpot associé, et la machine virtuelle
client est utilisée par défaut. La version AMD64 n'est accompagnée
que du serveur de machine virtuelle, le client n'a pas encore été
porté.
En général, le serveur est la machine virtuelle la plus rapide. Ses
compilateurs utilisent plus d'optimisations et sont plus aggressifs
que ceux de la machine virtuelle client. Il génère en général un
code bien meilleur.
La contrepartie est que ces optimisations ont un coût en temps CPU
et en mémoire. Ce qui fera que lancer du code dans la machine
virtuelle client est souvent plus rapide (au moins au début) que
sur la machine virtuelle serveur.
En d'autres termes : il n'est pas correct de comparer le client i386
avec le serveur AMD64. Vous devez comparer le serveur i386 (c'est à
dire « java -server ... ») avec le serveur AMD64.
</pre>
<p>
Il a également répondu à une question portant sur le temps d'attente à
espérer avant de pouvoir disposer de la machine virtuelle client :
</p>
<pre>
Elle ne sera pas présente dans la version finale de la 1.4.2. Ce ne
sera peut-être pas pour la 1.5.0 (pour Sun et Blackdown), Sun est
content de son port du serveur et n'est pas vraiment intéressé par
sortir un portage du client (les autres machines virtuelles 64 bits
pour IA64 et SPARC64 disposent également uniquement du serveur). De
plus, c'est trop de travail (je dirais dans les 10-13 semaines/homme)
pour le faire sans rémunération.
</pre>
<p>
Donc si vous voulez lancer des tests, soyez sport, utilisez « java
-server » sur les deux architectures concernées et n'espérez pas avoir une
version de machine virtuelle client d'ici un petit bout de temps.
</p>
<p>
Une fois que vous aurez installé java, le lien symbolique suivant est nécessaire
pour pouvoir l'utiliser avec mozilla (et probablement aussi konqueror) :
</p>
<pre>
/usr/lib/nsbrowser/plugins/libjavaplugin_oji.so -> \
/opt/blackdown-jdk-1.4.2_rc1/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
</pre>
</body>
</section>
<section>
<title>Installer OpenOffice.org</title>
<body>
<p>
OpenOffice.org n'est actuellement disponible qu'en binaire 32 bits, dans la
mesure où la version 1.1.x ne se compilera pas sur un AMD64. Pour installer
OpenOffice.org, installez le paquet <path>app-office/openoffice-bin</path>.
</p>
<note>
N'espérez même pas essayer de compiler OpenOffice.org à partir des sources.
C'est un effort vain qui ne vous mènera qu'à des nuits blanches inutiles.
</note>
</body>
</section>
<section>
<title>Configurer correctement les paramètres CFLAGS</title>
<body>
<p>
À la différence de gcc 3.3, gcc 3.4 demande que l'on utilise -march. Les
paramètres CFLAGS les plus appropriés pourraient être ceux-ci :
</p>
<pre caption="gcc-3.4 CFLAGS">
...
CFLAGS="-march=k8 -O2 -pipe"
...
</pre>
<note>
<c>-march=k8</c> est équivalent à <c>-march=athlon64</c> qui lui même l'est à
<c>-march=opteron</c>.
</note>
<p>
Il arrive qu'il y ait des problèmes avec la construction des objets partagés si
on omet le paramètre <c>-fPIC</c>. La raison est expliquée sur ce message de
liste de diffusion : <uri
link="http://www.x86-64.org/lists/discuss/msg02621.html">Porting to Hammer</uri>
-- Descendez à « Shared libraries must be compiled with -fPIC ». Si
vous trouvez des paquets qui ont besoin du paramètre <c>-fPIC</c> pour être
lancés/liés correctement, merci de nous les indiquer immédiatement, afin que
l'on puisse mettre à jour ces paquets. Merci de ne pas spécifier <c>-fPIC</c>
dans vos paramètres généraux CFLAGS dans la mesure où ce n'est pas une solution
acceptable, mais juste une petite astuce de contournement.
</p>
<p>
Ne mettez pas <c>-m32</c> dans vos paramètres USE, dans la mesure où vous ne
souhaiterez probablement pas compiler votre système en mode 32 bits. Par
défaut, Gentoo ne supporte de toute façon pas la compilation de binaires en
32 bits. Utiliser le paramètre <c>-m64</c> est inutile dans la mesure où le
compilateur utilisera le mode 64 bits par défaut et cela peut avoir des
effets négatifs sur le code qui dispose du paramètre <c>-m32</c> de manière
interne, pour compiler du binaire 32 bits (comme par exemple les dernières
versions de grub).
</p>
<warn>
N'utilisez pas <c>-Os</c>. C'est un paramètre connu pour empêcher des parties de
KDE 3.2.0 de compiler.
</warn>
</body>
</section>
<section>
<title>Paramètres USE qui sont ignorés</title>
<body>
<p>
Les paramètres USE <c>mmx</c>, <c>3dnow</c>, <c>sse</c> et <c>sse2</c> sont
ignorés sur AMD64, dans la mesure où tous les processeurs AMD64 supportent ces
jeux d'instructions. Ils sont ignorés car ils activent l'optimisation
32 bits d'assembleur pour certains paquets.
</p>
</body>
</section>
<section>
<title>Rapporter des bogues et soumettre des correctifs</title>
<body>
<p>
Si vous avez une application avec laquelle vous avez des problèmes, si vous
disposez d'un correctif pour corriger des problèmes ou simplement si vous voulez
rapporter une compilation réalisée avec succès afin que nous puissions en tenir
compte dans Portage, merci de rapporter un bogue sur <uri
link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
</p>
<note>
Vous pouvez mettre <mail link="amd64@gentoo.org">amd64@gentoo.org</mail> dans le
champ « CC: » si vous le souhaitez.
</note>
<note>
Pour soumettre un correctif, vous devez tout d'abord créer un rapport de bogue,
puis revenir sur le rapport et choisir « Create a new attachment ».
</note>
</body>
</section>
</sections>
|
GitWeb