php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74125 PHP 7.1.2 compilation and libcurl error
Submitted: 2017-02-18 20:41 UTC Modified: 2017-08-25 15:07 UTC
Votes:15
Avg. Score:3.9 ± 0.9
Reproduced:14 of 14 (100.0%)
Same Version:6 (42.9%)
Same OS:9 (64.3%)
From: krazitchek at hotmail dot com Assigned: remi (profile)
Status: Closed Package: Compile Failure
PHP Version: 7.1.2 OS: Debian 9 stretch 64bits
Private report: No CVE-ID: None
 [2017-02-18 20:41 UTC] krazitchek at hotmail dot com
Description:
------------
I tried to compile 7.1.2 as usually but this time ./configure fail with these error:

    checking for cURL in default path... not found
    configure: error: Please reinstall the libcurl distribution - easy.h should be in /include/curl/

I'm on Debian Stretch (9) 64 bits.

With 'locate easy.h' i found libcurl4-openssl-dev is installed in /usr/include/x86_64-linux-gnu/curl when ./configure expect it in/include/curl/`

libcurl4-openssl-dev on debian Jessie install curl in /usr/include/curl/ when Stretch install curl in /usr/include/x86_64-linux-gnu/curl.

With the last PHP version i compiled (7.1.1), i had no problems, but this time it failed.

To compile:
./buildconf --force && ./configure --prefix=/usr/local/php --with-config-file-path=/etc/php/lib --enable-bcmath --with-bz2 --with-zlib --enable-zip --enable-calendar --enable-exif --enable-ftp --with-gettext --with-gd --with-jpeg-dir --with-png-dir --with-freetype-dir --with-xpm-dir --enable-mbstring --enable-mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-openssl --enable-intl --enable-soap --with-readline --with-curl --with-mcrypt --with-xsl --enable-sockets

curl and libcurl4-openssl-dev packages are installed via apt-get.

I tried with --with-curl=/usr/include/x86_64-linux-gnu/curl/ but it doesn't work.

I'm not sure but i think something change in libcurl4-openssl-dev package in debian 8 jessie (packages.debian.org/fr/jessie/amd64/libcurl4-openssl-dev/…) and debian 9 stretch (packages.debian.org/fr/stretch/amd64/libcurl4-openssl-dev/…‌​). We can see on those two urls that path is not the same for the same package. Jessie version match requirement (/usr/include/curl/easy.h) while stretch version don't match requirement (/usr/include/x86_64-linux-gnu/curl/easy.h)


Patches

Add a Patch

Pull Requests

Pull requests:

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-02-19 08:04 UTC] krazitchek at hotmail dot com
libcurl4-openssl-dev for debian jessie:
https://packages.debian.org/fr/jessie/amd64/libcurl4-openssl-dev/filelist

libcurl4-openssl-dev for debian stretch:
https://packages.debian.org/fr/stretch/amd64/libcurl4-openssl-dev/filelist
 [2017-02-21 13:58 UTC] deadraid at yandex dot ru
sudo ln -s  /usr/include/x86_64-linux-gnu/curl  /usr/include/curl
 [2017-08-25 15:07 UTC] remi@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: remi
 [2017-08-25 15:07 UTC] remi@php.net
While this is obviously a bug in debian "curl-config not giving correct build options", this have been fixed in 7.0+ by

http://git.php.net/?p=php-src.git;a=commit;h=3fd7d819b8ea164bdf255cddcd0a1b1d156f4a3b

But IMHO using dpkg command is not acceptable, so a better fix have been applied in 7.2

http://git.php.net/?p=php-src.git;a=commit;h=b8c6ce91b24d314fe9f9996a17942b63ecec249b
 [2019-07-26 16:37 UTC] rg dot viza at gmail dot com
IMHO distro specific issues belong in their distro... It'd unreasonable to expect the configure/php people to keep up with every cockamamie place distro maintainers decide to put things. If you decide to put headers some place besides ../include[library name] you do so at the peril of your users. 

_every_ source package I've ever seen expects all libraries to be in [include]/[library name]. If the distro people put some stuff in [include]/[library name] and other stuff in [include]/[stupid place]/[library name], they're going to break compiling from source, unless the user is astute enough to add links as necessary.

The reason to decide on one place to put all headers is so configure can find --all-- dependencies, not just the dependency living in some weird place you pointed configures --include-dir  to. If you point the include directory to the weird place, configure won't be able to find anything but that specific library. The source following standards won't be found then.

This is a Debian problem. Hold them up to as an example of how NOT to organize a header directory.

If you need to be compiling stuff from source, pick another distro. Anything but Debian based.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Mon Sep 23 06:01:27 2019 UTC