A bit of history first: - from php-5.2.9-r2 build.log: /var/tmp/portage/dev-lang/php-5.2.9-r2/work/php-5.2.9/ext/curl/interface.c:68:6: warning: #warning "libcurl was compiled with GnuTLS support, but configure could not find " "gcrypt.h; thus no SSL crypto locking callbacks will be set, which may " "cause random crashes on SSL requests" - from php-5.2.10 build.log: /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/curl/interface.c:74:5: warning: #warning "libcurl was compiled with SSL support, but configure could not determine which" "library was used; thus no SSL crypto locking callbacks will be set, which may " "cause random crashes on SSL requests"
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
