[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: daap ovvero: Digital Audio Access Protocol...



Ciao Hugh,

sempre pronto e disponibile ad aiutare...

Forse e dico forse non potresti compilare i sorgenti nella dir apposita per questo scopo cioe': /usr/src o anche /usr/local/src e da root, anche se e' pericoloso ... infatti, tra i messaggi errore noto un permesso negato ...
poi make si lagna di non aver trovato il file Makefile.full (il file
Makefile e' assolutamente indispensabile per make, e' un file che contiene
le directory di installazione del sorgente compilato, le opzioni di
compilazione, le dir delle librerie, ecc, ecc ... insomma e' veramente
importante ... :-)

In genere, si copia il sorgente scompattato in /usr/src, si netra nella
directory del sorgente e, se e' presente uno script configure si lancia
#./configure che crea un file configure.h che contiene tutte le librerie e le utilities presenti sul sistema e inoltre verifica la fuinzionalita' del compuilatore e di altri programmi necessari allo sviluppo del sorgente ... poi, si lancia make e make install per installare i binari ottenuti di norma nella dir /usr/local/bin e le librerie in /usr/local/lib, le man page in
/usr/local/man/ e cosi via (basta esplorare il Makefile)

Naturlamente e' necessario vedere da quali pacchetti devel dipende il
pacchetto sorgente ... queste informazioni sono generalmente nei file README e INSTALL, naturalmente non tutti i pacchetti sorgenti sono eguali e quindi prima di compilare e' indispensabile verificare se nel proprio sitema Debian
sono presenti i vari pacchetti devel (libc6-devel, libjpg-devel, ecc)
Praticamente quasi ogni libreria ha la sua corrispondente-devel ....

e fai bene a dire "forse" due volte, anche se quello che dici è sacrosanto (ma però un poco didattico), vedrò di fare lo stesso e spiegare il perché...

Linux e gli altri "dialetti" UNIX hanno preso da UNIX anche la struttura "storica" delle directory di un volume dove è piuttosto rigida la posizione dei vari file di sistema. Ciò avviene poichè il sistema è modulare e i suoi "pezzi" possono essere aggiunti (o tolti) a seconda della necessità e dello spazio disponibili. La enorme flessibilità e forza di UNIX (e quindi Linux) nasce poi dal fatto che pur mantenendo formalmente rigida questa struttura di base è possibile usare al posto dei file canonici, dei puntatori (link) che indicano al sistema dove fisicamente si trovano i file o intere directory, oppure anche "montare" addirittura dei file-system esterni al volume di partenza da computer remoto.

Questo avviene un poco con /floppy e /cdrom che non sono delle directory vere e proprie ma solitamente contengono un link ad una periferica contenuta in /dev.

(perdonate il linguaggio un pò "rozzo" da principiante quale mi considero ma credo che tutto quanto sopra si chiami tecnicamente compatibilità "posix")

Quindi, ad esempio, è possibile (tramite nfs) avere la directory /home contenente gli utenti su un altro disco o computer remoto, basta indicare nel file /etc/fstab dove trovarla e cosa deve fare il sistema durante l'avvio.

Questo può essere molto utile, ad esempio, quando finisce lo spazio disponibile su un hard disk. Invece che rifare un'installazione (di debian :-) su uno più grande, è possibile aggiungere un'altro hard disk al computer e creare un symlink (link simbolico) dalla directory home sul volume di partenza alla home sul nuovo hard disk... Questo avviene in modo completamente "trasparente" all'utente (e al computer)

Similarmente avviene per le directory contenenti i comandi utente (e di sistema) che sono generalmente contenute in /bin e /sbin ed anche /usr/local/bin /usr/local/sbin (per non dimenticare /etc/X11R6 che contiene i comandi per il terminale grafico) ed altre ancora.

Quando installiamo un pacchetto nuovo, l'eventuale script di installazione posiziona i file aggiungendoli nelle varie /lib e anche in una delle directory che ho appena elencato e lo può fare, muovendo fisicamente il programma eseguibile (object) in posizione oppure creando un apposito lynk. Altrimenti è necessario effettuare questa operazione in manuale perché tutto funzioni correttamente.

Se questo non avviene, per eseguire un comando ci si posiziona sulla directory relativa e si digita ./comando oppure sh ./comando. Questo è il classico caso di ./configure dove per creare il Makefile necessario a compilare un programma è bene posizionarsi prima sulla directory del sorgente con un cd /usr/src/directory-sorgente e poi, alla fine dare il classico "make" e poi "make install". Nota bene che anche questo è possibile con dei symlink.... cioè /usr/src/link---> /directory-sorgente

Per completezza di questa brevissima introduzione è bene ricordare che la shell va a cercare i comandi nelle directory specificate in fase di boot da una apposita "dichiarazione" contenuta generalmente in un file di configurazione standard (in *BSD che conosco meglio sono i vari .rc) del tipo PATH= /bin: /sbin: /usr/local/bin /usr/local/sbin eccetera eccetera

Quando digitiamo un comando da tastiera (ma anche durante l'esecuzione di uno script di shell) la shell usata andrà quindi a cercare il comando nelle varie directory specificate nella variabile PATH e lo esegue altrimenti ci da un messaggio di errore del tipo "command not found" Questo è il motivo per cui possiamo accedere a certi comandi solo da "root" e ciò si specifica sempre nelle spiegazioni con # oppure % che sono un'indicazione alla condizione nella quale è necessario trovarsi per eseguire l'istruzione.

Ci sono inoltre due possibilità di indirizzare istruzioni in una shell (e in generale nei programmi): in modo assoluto (quando si digita la full path dell'istruzione es: /bin/sh: ./Makefile) o in modo relativo (come ad esempio con ~/ecc/eccetera indichiamo la directory "eccetera" all'interno di quella "ecc" all'interno della home dell'utente e così via)

Quindi, caro Hugh, tornando a noi, se osservi bene il sorgente di libhttpd (avevo lasciato il link apposta) ti accorgerai che all'inizio viene fatta una apposita dichiarazione di variabili (TOP) che usa poi lo script in modo da rendere indipendente la posizione del sorgente alla sua esecuzione.

Per quanto riguarda le necessarie librerie, in un sorgente dovrebbe sempre esserci un messaggio che indica quali sono quelle mancanti e in ogni caso chi a scritto il sorgente da delle indicazioni chiare in tal senso in README o INSTALL. Io non ho trovato niente di particolare. Comunque, come già detto, avevo compilato senza problemi le altre parti del programma.

Perdonate le tante inesattezze che avrò probabilmente messo nella mia introduzione, ma se sono riuscito ad incuriosire (e non addormentare) qualcun'altro che mi vuole aiutare è davvero il benvenuto.

Saluti a tutti

Pieter



Reply to: