Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » patch review for acinclude.m4 »

patch review for acinclude.m4

php.internals

Brian J. France

22 years ago
If there are no objections I plan on committing this tomorrow on both HEAD and PHP_4_3 branches. This fixes the openssl FreeBSD problem I posted about earlier. Is there a better way of fixing it? Brian Index: acinclude.m4 =================================================================== RCS file: /repository/php-src/acinclude.m4,v retrieving revision 1.264 diff -u -p -r1.264 acinclude.m4 --- acinclude.m4 3 Oct 2003 04:29:13 -0000 1.264 +++ acinclude.m4 13 Nov 2003 07:08:28 -0000 @@ -1659,6 +1659,10 @@ AC_DEFUN([PHP_SETUP_OPENSSL],[ -L$OPENSSL_LIBDIR ]) + dnl openssl on FreeBSD doesn't have a dependence on crypto + dnl force it + LIBS="$LIBS -lcrypto"; + PHP_CHECK_LIBRARY(ssl, SSL_CTX_set_ssl_version, [ PHP_ADD_LIBRARY(ssl,,$1) found_openssl=yes

Sascha Schumann

22 years ago
On Wed, 12 Nov 2003, Brian J. France wrote:
> If there are no objections I plan on committing this tomorrow on both HEAD and > PHP_4_3 branches. This fixes the openssl FreeBSD problem I posted about > earlier.
What is the problem here? 4.3.4 already checks this way: configure:16456: checking for SSL_CTX_set_ssl_version in -lssl configure:16475: ccache gcc -o conftest -O0 -Wall -Wl,-rpath,/usr/local/ssl/lib -L/usr/local/ssl/lib -Wl,-rpath,/usr/local/ssl/lib -L/usr/local/ssl/lib conftest.c -lssl -lcrypto -lresolv -lm -ldl -lnsl 1>&5 ^^^^^^^^^^^^^^^ - Sascha

Jani Taskinen

22 years ago
On Wed, 12 Nov 2003, Brian J. France wrote:
>If there are no objections I plan on committing this tomorrow on both HEAD and >PHP_4_3 branches. This fixes the openssl FreeBSD problem I posted about >earlier. > >Is there a better way of fixing it?
Yes, you shouldn't pollute LIBS like that. :) I committed a bit better fix for this. Hint: Don't compile extensions as shared..it really doesn't give you anything extra, just more problems like this. --Jani

Brian J. France

22 years ago
On Thu, 13 Nov 2003 16:19:23 +0200 (EET), Jani Taskinen wrote:
> On Wed, 12 Nov 2003, Brian J. France wrote: > Yes, you shouldn't pollute LIBS like that. :) > I committed a bit better fix for this.
Thank you!
> Hint: Don't compile extensions as shared..it really doesn't give > you anything extra, just more problems like this.
Yes, I agree that is true in almost 99.9% of all cases, but I am in that 0.1%. No point building snmp (or insert any other extension here) into our default PHP build for 3,000+ machines when only about 4 machines will be using it. Brian

Jani Taskinen

22 years ago
On Thu, 13 Nov 2003, Brian J. France wrote:
>> Hint: Don't compile extensions as shared..it really doesn't give >> you anything extra, just more problems like this. > >Yes, I agree that is true in almost 99.9% of all cases, but I am in that >0.1%. No point building snmp (or insert any other extension here) into our >default PHP build for 3,000+ machines when only about 4 machines will be using >it.
Heh, that's a good enough reason. :) --Jani

Rasmus Lerdorf

22 years ago
On Thu, 13 Nov 2003, Jani Taskinen wrote:
> Hint: Don't compile extensions as shared..it really doesn't give > you anything extra, just more problems like this.
Brian has a very good reason for compiling this stuff shared! ;) -Rasmus