| Summary: | >=dev-lang/php-5.2.9-r2: incorrect detection of curl' SSL lib with gnutls useflag | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Rafał Mużyło <galtgendo> |
| Component: | Current packages | Assignee: | PHP Bugs <php-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | patch for incorrect m4 macro | ||
|
Description
Rafał Mużyło
2009-06-24 02:52:17 UTC
Created attachment 195620 [details, diff]
patch for incorrect m4 macro
Now a patch and an explanation:
- I think 'save' vars bits are obvious
- HEADERS, not HEADER, cause we need HAVE_GCRYPT_H define
- now simply '-lcurl', instead of full 'curl-config --libs'
is my personal thing - as it works on an '--as-needed' system,
it should probably work on any sane system
On semi-related note: is there any point of '--host=${CHOST}' in php5_2-sapi.eclass besides causing this:
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
If that curl check change worries you, 'pkg-config libcurl --libs' may be used instead, it will have the same effect (barring la file pollution). Thanks for the contribution! I'll look into it. While i won't touch php-5.2.13 anymore, maybe it can find it's way into a possible php-5.2.14 or php-5.3 if the problem persists there. I've included the patch, minus the -lcurl bit, into my patchset, so the next patchset release will include the fix. I'm unsure if this warrants a revbump by itself, but chances are I'll gather a few fixes into a new release. Leaving the bug open until then. Sorry it took so long! Okay, I've retested this. But I can't verify the problem?
When is this supposed to occur? From my reading of interface.c you're facing a compile time warning. Building php-5.3.3-r2 yielded no such warning for me and gnutls was detected correctly.
Can you recheck that this problem still exists in php-5.{3.3-r2,2.14-r1}, please?
I was offline for almost 3 months.
dev-lang/php USE="apache2 bcmath berkdb bzip2 calendar cgi cjk cli crypt ctype curl curlwrappers doc exif fileinfo filter flatfile ftp gd-external gdbm gmp hash iconv imap inifile iodbc ipv6 json kerberos ldap ldap-sasl mysql mysqli nls pcntl pdo phar pic posix postgres readline session sharedext simplexml snmp soap sockets spell sqlite3 ssl suhosin sysvipc threads tidy tokenizer truetype unicode xml xmlreader xmlrpc xmlwriter xsl zip zlib -adabas -birdstep -cdb -concurrentmodphp -db2 -dbmaker -debug -embed -empress -empress-bcs -enchant -esoob -firebird -fpm -frontbase -gd -interbase -intl -kolab -libedit -mssql -mysqlnd -oci8 -oci8-instant-client -odbc -qdbm -recode -sapdb -sharedmem -solid -sqlite -sybase-ct -wddx -xpm"
net-misc/curl-7.20.1 USE="ares gnutls idn ipv6 kerberos ldap ssl -libssh2 -nss -test"
Yes, that's a compile time warning.
By gnutls, you mean "for gnutls support in libcurl" check ?
AC_CHECK_HEADER{,S} difference in behavior is most likely
due to use of old autoconf by upstream, where it may not have mattered.
See, if your php build defines HAVE_GCRYPT_H when it does check for gcrypt.h.
The source is clear, the warning happens if HAVE_CURL_OPENSSL is not defined, HAVE_CURL_GNUTLS is defined and HAVE_GCRYPT_H is not defined - last will
happen even if gcrypt.h is detected, as AC_CHECK_HEADER does not define it.
Both Matti and I have tried to reproduce this with latest versions of PHP, but are unable to do so. Please reopen if you still experience this issue. Cheers, Ole Markus |
