Attachment 53872 Details for Bug 85921 – translated[it] install-software.xml

translated[it] install-software.xml

install-software.xml (text/xml), 10.95 KB, created by Ludovico Poggioli on 2005-03-19 09:50:46 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Ludovico Poggioli

Created: 2005-03-19 09:50:46 UTC

Size: 10.95 KB

patch

obsolete

><?xml version='1.0' encoding='UTF-8'?>
>
><!DOCTYPE sections SYSTEM "/dtd/book.dtd">
>
>
>
>
><sections>
>
><version>2004.3</version>
><date>2005-02-19</date>
>
><section>
>	<title>Kernel Disponibili</title>
><subsection>
>	<title>Sul LiveCD</title>
><body>
><p>
>Fino alla 2004.3, c'Ã¨ un solo kernel disponibile sul LiveCD dal quale effettuare il boot. Questo kernel Ã¨ <c>gentoo</c> ed Ã¨ un kernel SMP. Le macchine non SMP possono usare comunque questo kernel.
></p>
></body>
></subsection>
><subsection>
>	<title>Utilizzare il Giusto Kernel</title>
><body>
><impo>Utilizzare il kernel <path>sys-kernel/gentoo-dev-sources</path>! Esso Contiene
>delle patch specifiche per AMD64, ed altre migliorie. Non saremo in grado di 
>fornirvi supporto se utilizzerete altri kernel.</impo>
></body>
></subsection>
><subsection>
>	<title>Costruire un Kernel per un Laptop eMachines</title>
><body>
><p>
>Prima di 2004.3, nel configurare un kernel da utilizzare con laptop eMachines Mobile Athlon64, l'utente <e>doveva</e> compilare il supporto USB nel kernel. In caso contrario, avrebbe ricevuto errori 
>riguardo del tipo "unknown keypress' da <path>atkbd.c</path>. Disabilitare il supporto USB non funzionava.
></p>
><p>
>Riscontri su quanto bene la 2004.3 funzioni con laptop eMachines dovranno essere riportati attraverso bugs.gentoo.org.
></p>
></body>
></subsection>
> <subsection>
>	<title>Kernel 2.4.x Ufficialmente Deprecato</title>
><body>
><p>
><b>La serie 2.4.x del kernel Ã¨ ufficialmente deprecata per AMD64.</b> Dalla 2.4.23-pre7. devfs
>Ã¨ stato disabilitato, essendo causa di memory corruption. In Gentoo non abbiamo avuto 
>esperienza di questi problemi, ma l'utilizzo di 2.4 senza devfs non Ã¨ una buona soluzione 
>per Gentoo.
></p>
></body>
></subsection>
><subsection>
>	<title>gcc 3.3 Ufficialmente Deprecato</title>
><body>
><p>
><b>gcc 3.3 Ã¨ ufficialmente deprecato per AMD64, dalla release 2004.3.</b> Tutto il LiveCD 2004.3 
>Ã¨ ora basato su gcc 3.4.x.
></p>
></body>
></subsection>
></section>
><section><title>Kernel Panic al Boot</title>
><body>
><p>
>Se l'utente avesse esperienzea di kernel panic all'avvio, puÃ² provare a passare <c>idle=poll</c> 
>come opzione al boot. Questo Ã¨ un problema che affligge molti BIOS attualmente e 
>principalmente le schede madri con chipset VIA. L'utente dovrÃ  passare questa opzione solo 
><e>dopo</e> aver aggiornato il BIOS all'ultima versione fornita dal produttore della 
>scheda madre. Si potrÃ  risolvere questo problema anche disabilitando il supporto Legacy USB 
>nel BIOS. Se si fosse costretti ad utilizzare l'opzione <c>idle=poll</c>, si prega di 
>contattare il produttore della scheda madre per la risoluzione della CPU Errata
>#93.
></p>
><p>
>Per ulteriori informazioni su questo tema, controllare questi archivi di mailing list:
></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>
>Potrete constatare come non sia un problema specifico di Gentoo!
></p>
></body>
></section>
>
><section><title>Filesystem Supportati</title>
><body>
><p>
>Raccomandiamo fortemente di utilizzare in questo momento ext2/3. Abbiamo avuto notizia 
>di problemi con reiserfs su AMD64, ed anche di problemi gravi utilizzando 
>JFS su sistemi 64-bit (Cosa che sembra paradossale considerando che Ã¨ stato 
>inizialmente pensato per l'utilizzo su sistemi 64-bit).
>
></p>
><table>
><tr>
> 	<th>Filesystem:</th>
>	<th>Stato:</th>
></tr>
><tr>
>	<ti>ext2</ti>
>	<ti>STABILE</ti>
></tr>
><tr>
>	<ti>ext3</ti>
>	<ti>STABILE</ti>
></tr>
><tr>
>	<ti>XFS</ti>
>	<ti>STABILE, >=gentoo-dev-sources-2.6.3</ti>
></tr>
><tr>
>	<ti>JFS</ti>
>	<ti>STABILE, >=gentoo-dev-sources-2.6.7</ti>
></tr>
><tr>
>	<ti>reiserfs</ti>
>	<ti>STABILE, >=gentoo-dev-sources-2.6.5</ti>
></tr>
><tr>
>	<ti>reiser4</ti>
>	<ti>NON FUNZIONA SU AMD64, NON SUPPORTATO SU NESSUNA ARCHITETTURA!</ti>
></tr>
></table>
><p>
>Vi preghiamo di riportare qualsiasi problema con qualunque filesystem su bgs.gentoo.org.
></p>
></body>
></section>
> 
><section><title>Il Bootloader: Compilare GRUB</title>
><body>
><p>
>Grub non compila in un'ambiente 64-bit puro. Compila solamente utilizzando gcc con multilib. 
>2004.3 include il supporto multilib di default. Se l'utente sceglierÃ  di rimuovere il supporto 
>multilib da gcc, dovrÃ  utilizzare <c>grub-static</c>. <c>grub-static</c> puÃ² essere 
>installato utilizzando le seguenti istruzioni:
>
></p>
><pre>
>emerge grub-static
>cp -Rpv /usr/share/grub/i386-pc/* /boot/grub
></pre>
></body>
></section>
> 
><section><title>Alcuni Pacchetti Sono Ancora Masked</title>
><body>
><p>
>Alcuni pacchetti che sono unmasked su altre architetture sono ancora masked 
>su AMD64. Questo non significa che non funzionino. Significa semplicemente che 
>nessuno sviluppatore Gentoo Ã¨ ancora stato in grado di testarli sulla propria 
>macchina AMD64. Vi preghiamo di testare le applicazioni masked e 
><uri link="http://bugs.gentoo.org">sottomettere un bug report</uri> mettendo 
>a conoscenza gli sviluppatori del fatto che un pacchetto funziona o no.
>
></p>
></body>
></section>
>
><section><title>Pacchetti che Non Funzionano</title>
><body>
><p>
>Attualmente non funziona:
></p>
><ul>
>	<li>Firebird (il database, NON il browser)</li>
></ul>
><p>
>Cose che non funzionano in modo 64-bit, ma che DOVREBBERO funzionare in modo 32-bit 
>(dando per assunto che app-emulation/emul-linux-x86-baselibs e compagnia siano 
>installati):
></p>
><ul>
>	<li>Qualsiasi programma che usi dll 32-bit da windows (come il supporto di mplayer/xine 
>	per alcuni formati proprietari)</li>
>	<li>Qualsiasi programma che richieda assembly 32-bit</li>
></ul>
></body>
></section>
>
><section><title>Supporto Java</title>
><body>
><p>
>Blackdown ha rlasciato un Java 64-bit nativo per Linux su AMD64. E' una 
>release candidate quindi non c'Ã¨ da aspettarsi la perfezione. E' in 
>portage come <path>blackdown-jdk-1.4.2</path> e <path>blackdown-jre-1.4.2</path>.
>
></p>
><p>
>Alcuni utenti hanno notato che la VM Java 64-bit sembra piÃ¹ lenta della VM 
>Java 32-bit. Juergen Kreileder di Blackdown Ã¨ stato abbstanza gntile da rispondere:
></p>
><pre>
>Attualmente la VM 64-bit Ã¨ piÃ¹ veloce della VM 32-bit in quasi tutti i 
>benchmark.
>
>La differenza che viene rilevata Ã¨ da attribuire piÃ¹ alle differenti 
>VM:
>La versione i386 viene fornita con l'HotSpot Client VM e l'HotSpot 
>Server VM, il Client VM Ã¨ quello che viene usato di default. La 
>versione 64-bit Ã¨ fornita solo con il Server VM, del Client VM non 
>Ã¨ ancora stato effettuato il port.
>
>In linea generale il Server VM Ã¨ il piÃ¹ veloce dei due. Il suo 
>compilatore effettua piÃ¹ ottimizzazioni ed Ã¨ piÃ¹ aggressivo del 
>compilatore del Client VM. Solitamente genera codice migliore. La 
>contropartita Ã¨ che fare piÃ¹ ottimizzazioni prende piÃ¹ tempo CPU e 
>memoria. A causa di questo fatto far girare del codice GUI sul Client 
>VM Ã¨ spesso piÃ¹ veloce (perlomeno inizialmente) che farlo girare 
>sul Server VM.
>
>In altre parole: non Ã¨ giusto confrontare il client i386 con il 
>server AMD64. Si dovrebbe confrontare il server i386 con il 
>server AMD64.
></pre>
><p>
>Inoltre, ha risposto su quando potebbe essere completato il client VM:
></p>
><pre>
>Non sarÃ  nella release 1.4.2. Difficilmente sarÃ  nella 1.5.0 (Sia Sun 
>che Blackdown), Sun Ã¨ soddisfatta del ServerVM e non Ã¨ realmente 
>interessata nel porting del Client VM (Le altre VM 64-bit, per IA64 &amp; 
>SPARC64, sono anche loro solo Server VM). Ed Ã¨ troppo lavoro (Stimo 10-13 
>settimane uomo) per farlo senza essere pagati.
></pre>
><p>
>Quindi se volete fare dei benchmark, ed essere giusti, fate girare il 
>java-server su entrambe le architetture, e non aspettatevi che il 
>client vm arrivi troppo presto. ;)
></p>
><p>
>Una volta che si Ã¨ installato java, il seguente symlink Ã¨ richiesto per 
>per far si che lavori con mozilla (e probabilmente 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>Installare OpenOffice</title>
><body>
><p>
>OpenOffice Ã¨ attualmente disponibile solo in forma binaria 32-bit, poichÃ¨ OpenOffice 1.1.x non compila su AMD64. 
>Per installare OpenOffice, fare l'emerge del pacchetto <path>app-office/openoffice-bin</path>.
></p>
><note>Non consigliamo di provare a compilare OpenOffice dai sorgenti.E' uno sforzo futile e causerebbe solamente notti insonni.</note>
></body>
></section>
>
><section><title>Settare Propriamente le CFLAGS</title>
><body>
><p>
>Diversamente da gcc 3.3, gcc 3.4 richiede che sia settato -march. Le piÃ¹ conservative (e supportate) 
>CFLAGS possono essere impostate come segue:
></p>
><pre caption="gcc-3.4 CFLAGS">
>...
>CFLAGS="-march=k8 -O2 -pipe"
>...
></pre>
><note>
><c>-march=k8</c> Ã¨ uguale a <c>-march=athlon64</c> ed Ã¨ uguale a <c>-march=opteron</c>.
></note>
><p>
>Ci sono stati dei problemi per la mancanza dell'utilizzo di <c>-fPIC</c> nella 
>costruzione di oggetti condivisi, la ragione Ã¨ in un post della mailing list: 
> <uri link="http://www.x86-64.org/lists/discuss/msg02621.html">Porting to
>Hammer</uri> -- proseguite fino a  "Shared libraries must be compiled with -fPIC".
>Se l'utente trovasse qualsiasi pacchetto che necessiti di <c>-fPIC</c> per 
>funzionare correttamente, ci metta immediatamente a conoscenza, poichÃ¨ 
>dovremo aggiornare il pacchetto. Vi preghiamo di non specificare <c>-fPIC</c> 
>nelle CFLAGS poichÃ¨ non sarebbe una soluzione ma solamente un workaround.
></p>
><p>
>Vi preghiamo di non aggiungere <c>-m32</c> alle flag USE, poichÃ¨ voi non volete
>compilare il sistema in modo 32-bit, e di default Gentoo non supporta la compilazione 
>di binari 32-bit. L'utilizzo di <c>-m64</c> Ã¨ irrilevante poichÃ¨ il compilatore Ã¨ 
>per default in modo 64-bit e puÃ² avere effetti negativi sul codice che 
>fornisce internamente <c>-m32</c> per compilare assembly 32bit (come faranno le 
>prossime versioni di GRUB).
></p>
><warn>Non utilizzare <c>-Os</c>. E' noto per causare la mancata compilazione di parti di KDE 3.2.0.</warn>
></body>
></section>
> 
><section><title>Flag USE che vengono ignorate</title>
><body>
><p>
>Le USE flag <c>mmx</c>, <c>3dnow</c>, <c>sse</c> e <c>sse2</c> vengono ignorate 
>su AMD64, poichÃ¨ tutti i processori AMD64 supportano questi set di istruzioni. 
>Sono ignorate in quanto abilitano ottimizzazioni assembly 32bit per alcuni pacchetti.
></p>
></body>
></section>
> 
><section><title>Riportare Bug e Sottomettere Patch</title>
><body>
><p>
>Se l'utente avesse una patch per risolvere problemi con un pacchetto, o 
>volesse riportare una compilazione riuscita in modo da poterla riportare 
>in portage, Ã¨ pregato di sottomettere un bug report su <uri
>link="http://bugs.gentoo.org">bugs.gentoo.org</uri>.
></p>
><note>PuÃ² anche mettere nel campo CC: <mail link="amd64@gentoo.org">amd64@gentoo.org</mail> se vuole.</note>
><note>Per sottomettere una patch, si dovrÃ  prima sottomettere un bug report, 
>poi tornare al bug report e selezionare "Create a new attachment".</note>
></body>
></section>
>
></sections>

Actions: View

Attachments on bug 85921: 53872 | 53955