[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ successivo ]
Debian GNU/Linux include il codice sorgente per tutti i programmi inclusi, così
dovrebbe funzionare su tutti i sistemi che sono supportati dal kernel Linux; si
veda la Linux
FAQ
per i dettagli.
L'attuale release Debian GNU/Linux 4.0 contiene una distribuzione binaria completa per le seguenti architetture:
i386: questa comprende i PC basati su processori Intel e compatibili, inclusi gli Intel 386, 486, Pentium, Pentium Pro, Pentium II (sia Klamath che Celeron) e Pentium III e la maggior parte dei processori compatibili di AMD, Cyryx ed altri.
m68k: questa comprende computer Amiga e Atari con processori Motorola 680x0 (con x>=2) con MMU.
alpha: sistemi Alpha Compaq/Digital.
sparc: questa comprende i sistemi SPARC della Sun e la maggior parte dei sistemi UltraSPARC.
powerpc: questa comprende alcune macchine PowerPC IBM/Motorola, incluse le macchine CHRP, PoverMac e PReP.
arm: macchine ARM e StrongARM.
mips: sistemi MIPS big-endian della SGI, Indy e Indigo2; mipsel: macchine MIPS little-endian, Digital DECstations.
hppa: macchine PA-RISC della Hewlett-Packard (712, C3000, L2000, A500).
ia64: computer Intel IA-64 ("Itanium").
s390: sistemi mainframe IBM S/390.
Lo sviluppo di distribuzioni binarie di Debian per architetture Sparc64 (UltraSPARC nativo) è attualmente in corso.
Per ulteriori informazioni su come fare il boot, partizionare il proprio drive,
abilitare i dispositivi PCMCIA (PC Card) e per questioni simili si seguano le
istruzioni date nel manuale di installazione, che è disponibile dal nostro sito
WWW su http://www.debian.org/releases/stable/installmanual
.
Gli sviluppatori Debian comunicano con i produttori delle altre distribuzioni Linux per fare di tutto per mantenere la compatibilità binaria attraverso le distribuzioni. La maggior parte dei prodotti commerciali per Linux funziona bene sotto Debian come sul sistema su cui è stata compilati.
Debian GNU/Linux aderisce al Linux
Filesystem Hierarchy Standard
(Standard per la Gerarchia del
Filesystem Linux). Comunque, c'è la possibilità di interpretare alcune regole
all'interno di questo standard, così ci possono essere differenze tra un
sistema Debian e gli altri sistemi Linux.
Per la maggior parte delle applicazioni il codice sorgente di Linux è compatibile con altri sistemi Unix. Supporta quasi qualsiasi cosa che sia disponibile per i sistemi Unix basati su System V ed i sistemi liberi e commerciali derivati da BSD. Comunque nel mondo Unix una tale affermazione non ha quasi nessun valore perché non c'è modo di provarla. Nell'area di sviluppo del software è richiesta una completa compatibilità piuttosto della compatibilità nella "quasi maggioranza" dei casi. Così, anni fa, è sorta la necessità della presenza di standard e al giorno d'oggi POSIX.1 (IEEE Standard 1003.1-1990) è uno dei maggiori standard per la compatibilità del codice sorgente nei sistemi operativi Unix-like.
Linux si propone di aderire al POSIX.1, ma gli standard POSIX hanno un costo elevato e la certificazione di POSIX.1 (e FIPS 151-2) è abbastanza costosa; questo crea molte difficoltà agli sviluppatori Linux a lavorare per una completa conformità a POSIX. Il costo della certificazione rende improbabile che Debian fornisca una certificazione di conformità ufficiale anche se ha completamente superato la validation suite. (La validation suite è ora liberamente disponibile, così è previsto che più persone lavoreranno sui problemi di POSIX.1.)
L'Unifix GmbH (Braunschweig, Germania) ha sviluppato un sistema Linux che è stato certificato come conforme al FIPS 151-2 (un superset di POSIX.1). Questa tecnologia era disponibile nella distribuzione di Unifix chiamata Unifix Linux 2.0 e nel Linux-FT della Lasermoon.
Differenti distribuzioni Linux usano differenti formati dei pacchetti e differenti programmi di gestione dei pacchetti.
È disponibile un programma per spacchettare un pacchetto Debian all'interno di un sistema Linux in cui è stata installata una distribuzione 'straniera', e generalmente funzionerà, nel senso che quei file verranno spacchettati. Anche l'inverso è probabilmente vero, cioè, un programma che apre un pacchetto RedHat o Slackware su di un sistema basato su Debian GNU/Linux probabilmente riuscirà a spacchettare il pacchetto e a mettere la maggior parte dei file nelle directory di destinazione appropriate. Questo è in gran parte una conseguenza dell'esistenza del (e spiccata aderenza al) Linux Filesystem Hierarchy Standard.
La maggior parte dei gestori dei pacchetti scrive alcuni file di amministrazione quando vengono usati per spacchettare un archivio. Questi file di amministrazione sono generalmente non standardizzati. Quindi, l'effetto di aprire un pacchetto Debian su un sistema 'straniero' avrà risultati imprevedibili (certamente non utili) sul gestore dei pacchetti su quel sistema. Similmente, le utilità di un'altra distribuzione possono riuscire ad aprire i loro archivi su sistemi Debian, ma probabilmente causeranno dei guasti al sistema di gestione dei pacchetti Debian al momento di aggiornare o rimuovere alcuni pacchetti, o anche semplicemente nel riportare esattamente che pacchetti sono presenti sul sistema.
Il Linux File System Standard (e quindi Debian GNU/Linux) richiede che le sottodirectory che si trovano sotto /usr/local/ siano interamente sottoposte alla discrezione dell'utente. Quindi, gli utenti possono spacchettare pacchetti 'stranieri' dentro queste directory e poi possono gestire individualmente la loro configurazione, aggiornamento e rimozione.
Avete ancora un programma del genere? :-)
Per eseguire un programma il cui binario è in formato a.out (i.e., QMAGIC o ZMAGIC),
Ci si assicuri che il proprio kernel abbia il supporto per a.out compilato al suo interno, direttamente (CONFIG_BINFMT_AOUT=y) o come un modulo (CONFIG_BINFMT_AOUT=m). (Il pacchetto kernel-image di Debian contiene il modulo binfmt_aout.)
Se il proprio kernel ha il supporto dei binari a.out come modulo, ci si assicuri poi che il modulo binfmt_aout sia caricato. Si può fare questo all'avvio aggiungendo la riga binfmt_aout nel file /etc/modules. Lo si può fare da riga di comando eseguendo il comando insmod DIRNAME/binfmt_aout.o dove DIRNAME è il nome della directory dove sono memorizzati i moduli che sono stati compilati per la versione del kernel che è ora in esecuzione. Su un sistema con la versione 2.2.17 del kernel, DIRNAME è probabilmente /lib/modules/2.2.17/fs/.
Si installi il pacchetto libc4
, che si può trovare in una delle
release precedenti alla 2.0 (perché in questo momento abbiamo rimosso il
pacchetto). Si può vedere in un vecchio CD-ROM Debian (Debian 1.3.1 ha ancora
questo pacchetto), o si veda ftp://archive.debian.org/debian-archive/
su Internet.
Se il programma che si vuole eseguire è un client X nel formato
a.out, allora si installi il pacchetto xcompat
(si
veda sotto per la disponibilità).
Se si ha un'applicazione commerciale nel formato a.out, ora sarebbe il momento buono per chiedere l'invio dell'aggiornamento a ELF.
Sì. Basta installare le librerie libc5
richieste, dalla sezione
oldlibs (contenente vecchi pacchetti inclusi per la compatibilità
con altre applicazioni).
Sì. Si installino i pacchetti libc5-altdev
e altgcc
(dalla sezione oldlibs). Si possono trovare gli appropriati
gcc
e g++
compilati con libc5 nella directory
/usr/i486-linuxlibc1/bin. Li si metta nella propria variabile
$PATH per fare in modo che make
e altri programmi li eseguano per
primi.
Se si ha bisogno di compilare dei client X basati su libc5, si installino i
pacchetti xlib6
e xlib6-altdev
.
Si faccia attenzione che l'ambiente basato su libc5 non è più pienamente supportato dagli altri nostri pacchetti.
I file sotto la directory /usr/local/ non sono sotto il controllo del sistema di gestione dei pacchetti Debian. Quindi, è buona abitudine mettere il codice sorgente del proprio programma in /usr/local/src/. Per esempio, si potrebbe estrarre i file da un pacchetto che si chiama "foo.tar" dentro la directory /usr/local/src/foo. Dopo averli compilati, si mettano i file binari in /usr/local/bin/, le librerie in /usr/local/lib/ e i file di configurazione in /usr/local/etc/.
Se i propri programmi e/o file devono essere realmente messi in altre directory, si potrebbe ancora memorizzarli in /usr/local/ e creare i link simbolici appropriati dalla locazione richiesta alla loro locazione in /usr/local/, p.e., si potrebbe creare il link
ln -s /usr/local/bin/foo /usr/bin/foo
In ogni caso, se si ottiene un pacchetto il cui copyright permette la redistribuzione, si dovrebbe considerare di trasformarlo in un pacchetto Debian e caricarlo per il sistema Debian. Le linee guida per iniziare a sviluppare un pacchetto sono incluse nel Debian Policy manual (si veda Quale altra documentazione esiste su e per un sistema Debian?, Sezione 11.1).
Questo messaggio d'errore potrebbe significare che il programma è stato linkato
con la versione libc5 delle librerie X11. In questo caso è
necessario installare il pacchetto xlib6
, dalla sezione
oldlibs.
Si possono ottenere messaggi d'errore simili che si riferiscono al file
libXpm.so.4, in tal caso è necessario installare la versione di libc5 della
libreria XPM, dal pacchetto xpm4.7
, anch'esso nella sezione
oldlibs.
Debian usa il database terminfo e la libreria di interfaccia a terminale ncurses, piuttosto del database termcap e della libreria termcap. Gli utenti che stanno compilando dei programmi che richiedono alcune conoscenze sulle interfacce dei terminali dovrebbero sostituire i riferimenti a libtermcap con i riferimenti a libncurses.
Per supportare i file binari che sono già stati linkati con la libreria
termcap e per i quali non si ha il sorgente, Debian fornisce un
pacchetto chiamato termcap-compat
. Questo fornisce sia la
libtermcap.so.2 che /etc/termcap. Si installi questo
pacchetto se il programma non riesce ad avviarsi con il messaggio d'errore
"can't load library 'libtermcap.so.2'", o reclama la mancanza del
file /etc/termcap file.
AccelX usa la libreria termcap per l'installazione. Si veda Perché non posso compilare programmi che richiedono libtermcap?, Sezione 3.10 sopra.
È necessario installare il pacchetto motifnls
, che fornisce i file
di configurazione di XFree-2.1 necessari a permettere che le applicazioni
Motif, compilate sotto XFree-2.1, possano funzionare anche sotto XFree-3.1.
Senza questi file, alcune applicazioni Motif compilate su altre macchine (come Netscape) possono andare in crash nel tentativo di copiare o incollare da o a un campo di testo, e si possono presentare anche altri problemi.
[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ successivo ]
The Debian GNU/Linux FAQ
versione 4.0.4, 6 August 2008