Problemi di installazione

Questa sezione raccoglie i più comuni errori che avvengono durante l'installazione.

Ho l'ultima versione di PHP e uso l'accesso anonimo a Git, ma non c'è nessuno script per la configurazione!

Per generare lo script di configurazione dal file configure.in occorre avere il pacchetto autoconf di GNU installato sul PC. Si esegua ./buildconf nella cartella di livello più alto dopo aver ottenuto i sorgenti dal server Git. (A meno che si esegua configure con l'opzione --enable-maintainer-mode, lo script di configurazione non ricostruirà automaticamente lo script quando il file configure.in è aggiornato, quindi occorre accertarsi di farlo manualmente quando ci si accorge che il file configure.in è cambiato. Un sintomo di questo problema è la presenza di elementi come a @VARIABLE@ nel Makefile dopo aver eseguito la configurazione o il config.status.)

Ho problemi nel configurare PHP per farlo lavorare con Apache. Dice che è impossibile trovare il file httpd.h, ma questo è nel percorso che ho specificato!

Nello script di configurazione/setup occorre specificare il percorso della cartella di livello più alto di Apache, quindi si deve scrivere --with-apache=/path/to/apache e non --with-apache=/path/to/apache/src.

Durante la configurazione di PHP (./configure), si può incontrare un errore simile al seguente:

checking lex output file root... ./configure: lex: command not found configure: error: cannot find output from lex; giving up

Leggere attentamente le istruzioni di installazione e ricordarsi che per compilare il PHP occorre disporre sia di flex sia di bison. In base al proprio sistema si dovrà installare bison e flex dai sorgenti o da pacchetti tipo RPM.

Quando avvio Apache ottengo il seguente messaggio:

fatal: relocation error: file /path/to/libphp4.so: symbol ap_block_alarms: referenced symbol not found

Questo errore solitamente accade quando si compila il cuore di Apache come libreria DSO per utilizzo condiviso. Provare a riconfigurare Apache, prestando attenzione all'impostazione dei seguenti flag:

--enable-shared=max --enable-rule=SHARED_CORE

Per maggiori dettagli leggere INSTALL nella directory principale di Apache, oppure le pagine del manuale DSO.

Quando eseguo la configurazione, un messaggio di errore mi dice che non è possibile trovare file inclusi o librerie per GD, gdbm o qualche altro pacchetto!

Puoi ordinare allo script di configurazione di cercare di gli header e le librerie anche in posizioni non standard specificando flag addizionali da passare al preprocessore C, come: CPPFLAGS=.I/percorso/da/includere LDFLAGS=-L/percorso/per/la/libreria ./configure Se usi una variante di csh come shell di login (perché?), il codice diventa: env CPPFLAGS=-I/percorso/da/includere LDFLAGS=-L/percorso/per/la/libreria ./configure

Quando cerco di compilare il file language-parser.tab.c, un messaggio di errore mi dice yytname undeclared.

Devi aggiornare la tua versione di Bison. Puoi trovare l'ultima versione su Bison.

Quando eseguo make sembra che vada tutto bene, ma lo script si blocca quando cerca di creare un collegamento all'applicazione finale, un messaggio di errore dice che non è possibile trovare alcuni file.

Qualche vecchia versione di make non mette le versioni compilate dei file nelle cartelle giuste. Prova ad eseguire cp *.o functions e quindi e rieseguire make e controlla se il messaggio di errore compare ancora. Se dovesse continuare ad apparire avrai bisogno di scaricare una versione più recente di make GNU.

Quando linko PHP, un messaggio di errore mi avvisa di parecchie undefined reference.

Controlla la linea relativa al link ed assicurati che tutte le librerie appropriate siano state incluse alla fine dello script. Le librerie più comuni che tu possa aver scordato sono le '-ldl' e quelle relative al supporto di qualche database che hai incluso.

Qualcuno che aveva problemi a linkare Apache ha risolto aggiungendo '-ldl' subito dopo libphp4.a.

Ho seguito le istruzioni per installare Apache come modulo sotto UNIX, ma il browser mi mostra il codice dei miei script PHP o mi viene chiesto di salvare la pagina PHP sul disco.

Questo significa che il modulo PHP non viene invocato correttamente per una qualche ragione. Prima di cercare ulteriore aiuto controlla tre cose: Assicurati che l'httpd binario che stai eseguendo sia quello nuovo che hai appena installato. Per fare ciò prova ad eseguire: /percorso/per/il/file/eseguibile/httpd -l Se nell'elenco non compare mod_php4.c, significa che non stai eseguendo il binario giusto: trova ed installa il binario corretto. Assicurati di aver aggiunto il corretto Myme Type ad uno dei tuoi file Apache .conf. Dovrebbe essere: AddType application/x-httpd-php .php Assicurati anche che questa linea AddType non sia nascosta all'interno di un LtVirtualhostGt o di un blocco di LtDirectoryGt che possa impedire l'applicazione al percorso dei tuoi script di prova. Infine sappi che il percorso predefinito del file di configurazione di Apache 1.2 è diverso da quello di Apache 1.3. Dovresti controllare che il file a cui stai aggiungendo la linea AddType sia effettivamente letto. Puoi inserire appositamente un errore di sintassi nel file Httpd conf o effettuare qualche altro cambiamento che ti farà capire se il file è correttamente letto.

Un messaggio di errore mi dice di usare: --activate-module=src/modules/php4/libphp4.a, ma questo file non esiste, quindi l'ho cambiato in --activate-module=src/modules/php4/libmodphp4.a ma il tutto non funziona. Che succede?

Nota che si presume che il file libphp4.a non esista ancora. Sarà un processo di Apache a crearlo!

Quando provo ad installare Apache con PHP come modulo statico usando --activate-module=src/modules/php4/libphp4.a un messaggio di errore mi dice che il mio compilatore non è compatibile con ANSI.

Questo è un messaggio d'errore ingannevole di Apache, un bug che è stato corretto nelle versioni più recenti.

Quando provo ad installare Apache usando --with-apxs ricevo uno strano messaggio di errore.

Per risolvere questo problema devi controllare tre cose. Per iniziare, per qualche ragione, quando Apache installa gli script Perl apxs, ogni tanto finisce senza il compilatore appropriato e le variabili flag. Trova il tuo script apxs (prova il comando which apxs), ogni tanto lo trova in /usr/local/apache/bin/apxs o in /usr/sbin/apxs. Aprilo e cerca linee simili a queste: my $CFG_CFLAGS_SHLIB = ' '; # substituted via Makefile.tmpl my $CFG_LD_SHLIB = ' '; # substituted via Makefile.tmpl my $CFG_LDFLAGS_SHLIB = ' '; # substituted via Makefile.tmpl Se vedi scritto esattamente questo, hai trovato il problema: queste linee potrebbero contenere spazi o altri valori sbagliati, come 'q()'. Cambia le linee precedenti come segue: my $CFG_CFLAGS_SHLIB = '-fpic -DSHARED_MODULE'; # substituted via Makefile.tmpl my $CFG_LD_SHLIB = 'gcc'; # substituted via Makefile.tmpl my $CFG_LDFLAGS_SHLIB = q(-shared); # substituted via Makefile.tmpl Il secondo problema possibile potrebbe solo essere una particolare distribuzione di Red Hat 6.1 e 6.2. L'unità degli script apxs in Red Hat non è funzionante. Cerca una linea simile a questa: my $CFG_LIBEXECDIR = 'modules'; # substituted via APACI install Se trovi una linea identica a quella precedente, cambiala come segue: my $CFG_LIBEXECDIR = '/usr/lib/apache'; # substituted via APACI install Infine, se hai riconfigurato o reinstallato Apache, aggiungi un make clean al processo dopo ./configure e prima di make.

Quando eseguo make, ricevo errori nei microtime e un sacco di errori RUSAGE_.

Se durante la parte di installazione che riguarda make hai incontrato problemi simili a questi, significa che il tuo sistema ha qualche problema: microtime.c: In function `php_if_getrusage': microtime.c:94: storage size of `usg' isn't known microtime.c:97: `RUSAGE_SELF' undeclared (first use in this function) microtime.c:97: (Each undeclared identifier is reported only once microtime.c:97: for each function it appears in.) microtime.c:103: `RUSAGE_CHILDREN' undeclared (first use in this function) make[3]: *** [microtime.lo] Error 1 make[3]: Leaving directory `/home/master/php-4.0.1/ext/standard' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/master/php-4.0.1/ext/standard' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/master/php-4.0.1/ext' make: *** [all-recursive] Error 1

Hai bisogno di fissare alcuni tuoi file in /usr/include installando un pacchetto glibc-devel che corrisponda al tuo glibc. Questo non ha assolutamente niente a che fare con PHP. Per controllare se il tuo problema dipende da questo, prova questo semplice test: $ cat >test.c <<X #include <sys/resource.h> X $ gcc -E test.c >/dev/null Se ricevi messaggi d'errore, allora i tuoi file include sono in disordine.

Quando si compila il PHP con MySQL, la configurazione viene eseguita correttamente, ma durante il make si ottiene un errore simile al seguente: ext/mysql/libmysqlclient/my_tempnam.o(.text+0x46): In function my_tempnam': /php4/ext/mysql/libmysqlclient/my_tempnam.c:103: the use of tempnam' is dangerous, better use mkstemp', che cosa c'è di sbagliato?

Primo, è importante realizzare che questo è un Warning e non un errore fatale. Poiché spesso questo è l'ultimo messaggio visibile durante il make, sembra indicare un errore fatale, ma non lo è. Certamente, se si imposta il compilatore ad uscire anche sui warning, questo lo farà. Ricordarsi inoltre, che il supporto per MySQL è abilitato per default.

Voglio aggiornare il mio PHP. Dove posso trovare la linea di ./configure che è stata usata per creare la mia attuale versione di PHP?

Puoi cercare nel file config.nice nel sorgente della tua attuale installazione di PHP o eseguire questo semplice script: <?php phpinfo(); ?> Nella prima parte della pagina risultante è mostrata la linea ./configure usata durante la precedente installazione di PHP.

Quando si compila il PHP con la libreria GD, si ottiene dei strani errori di compila oppure dei segfault durante l'esecuzione.

Essere certi che la libreria GD e PHP condividano le medesime librerie (ad esempio libpng).

Quando si compila il PHP sembra di avere errori casuali, tipo blocchi. Se interessa sto utilizzando Solaris.

L'uso di utility non GNU per la compila del PHP può creare problemi. Occorre essere certi di utilizzare i tool GNU per essere certi della corretta compila del PHP. Ad esempio, con Solaris, l'utilizzo di SunOS BSD-compatibile con la versione di Solaris di sed crea dei problemi, ma utilizzando la versione GNU o Sun POSIX (xpg4) di sed non si avranno problemi. Riferimenti: GNU sed, GNU flex e GNU bison.