Pillole PHP: gestire le estensioni

Per vedere dove sono installate le estensioni (i codici oggetto .so che realizzano i plugin come i connettori a database, l’uso delle funzioni cURL etc):

marcob@jsbach[12:15:08]:php$ php-config --extension-dir
/usr/lib/php/20190902

Per abilitare il modulo curl per la versione 7.4

$ phpenmod -v 7.4 curl

Ho però un problema, l’installazione della libreria curl mi ha provocato una serie di errori che vengono stapati ad ogni invocazione dell’interprete php client o ad ogni riavvio di Apache:

root@jsbach[11:26:44]:apache2$ php -v
PHP Warning:  PHP Startup: Unable to load dynamic library 'curl' (tried: /usr/lib/php/20190902/curl (/usr/lib/php/20190902/curl: cannot open shared object file: No such file or directory), 
/usr/lib/php/20190902/curl.so (/usr/lib/php/20190902/curl.so: symbol curl_mime_addpart version CURL_OPENSSL_4 not defined in file libcurl.so.4 with link time reference)) in Unknown on line 0
PHP 7.4.2 (cli) (built: Feb  1 2020 17:49:29) ( NTS )

Seguo questo howto su Github

root@jsbach[11:25:47]:apache2$ sudo ldd /usr/lib/php/20190902/curl.so
/usr/lib/php/20190902/curl.so: /usr/local/lib/libcurl.so.4: no version information available (required by /usr/lib/php/20190902/curl.so)
    linux-vdso.so.1 (0x00007fffea95f000)<br>
    libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x00007f5924bd3000)

Come evidenziato dal comando esiste un conflitto tra la versione di libcurl installata in passato (/usr/local/lib/libcurl.so.4) e quella nuova (/usr/lib/php/20190902/curl.so); decido di rinominare quella vecchia:

root@jsbach[11:34:45]:apache2# cd /usr/local/lib/
root@jsbach[11:35:58]:lib# ls -l | grep 'curl'
-rw-r--r-- 1 root root  1006444 mag 23  2017 libcurl.a
-rwxr-xr-x 1 root root     1042 mag 23  2017 libcurl.la
lrwxrwxrwx 1 root root       16 mag 23  2017 libcurl.so -> libcurl.so.4.4.0
lrwxrwxrwx 1 root root       16 mag 23  2017 libcurl.so.4 -> libcurl.so.4.4.0
-rwxr-xr-x 1 root root   542272 mag 23  2017 libcurl.so.4.4.0
root@jsbach[11:36:04]:lib# mv libcurl.so.4.4.0 libcurl.so.4.4.0.OLD
root@jsbach[11:38:53]:lib# ldd /usr/lib/php/20190902/curl.so
	linux-vdso.so.1 (0x00007fff9610f000)
	libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f8d92a92000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8d926a1000)

Adesso il comando ldd (List Dynamic Library, che ci dice quali sono le librerie collegate ad un executable) non mostra più l’errore

root@jsbach[11:38:53]:lib# ldd /usr/lib/php/20190902/curl.so
	linux-vdso.so.1 (0x00007fff9610f000)
	libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f8d92a92000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8d926a1000)
...

Altro problema. Eseguento il comando php -m (o qualsiasi comando che usa l’interprete php client) ho un Warning:

root@jsbach[11:55:43]:lib# php -m
PHP Warning:  Module 'curl' already loaded in Unknown on line 0
[PHP Modules]
calendar
Core
ctype
curl
date

Il problema è che carico due volte la libreria, una specificando nominalmente il modulo curl nelle extensions

root@jsbach[12:10:32]:cli# pwd
/etc/php/7.4/cli
root@jsbach[12:10:34]:cli# cat php.ini | grep curl
extension=curl
[curl]
;curl.cainfo =

e una a causa della presenza del file singolo di load nelle configurazioni:

root@jsbach[12:11:00]:cli# ll conf.d/ | grep curl
lrwxrwxrwx 1 root root   36 feb  4 16:23 20-curl.ini -> /etc/php/7.4/mods-available/curl.ini

Commento la riga extensions=curl del file /etc/php/7.4/cli/php.ini. Il comando ora da un ouput pulito:

root@jsbach[12:11:45]:cli# php -m
[PHP Modules]
calendar
Core
ctype
curl
date
...

Anche il riavvio di Apache ora è pulito:

marcob@jsbach[12:15:23]:php$ sudo service apache2 restart
marcob@jsbach[12:24:48]:php$ 

Inoltre ora phpinfo() mostra il modulo correttamente caricato: