Elizabeth M Smith | 1 May 02:34 2008
Picon

[PHP-DEV] Re: PHP 5.2.6RC5 windows build available

Holo wrote:
> Rob Richards escreveu:
>> A little late to the party, but the windows build for PHP 5.2.6RC5 is
>> finally available. Please test it as much as possible.
>>
>> http://pecl2.php.net/downloads/php-windows-builds/qa/php-5.2.6RC5-Win32.zip
>>
>> http://pecl2.php.net/downloads/php-windows-builds/qa/php-debug-pack-5.2.6RC5-Win32.zip
>>
>>
>> The non-ts build will only be available for the release of 5.2.6
>>
>> Rob
>>
> Hi
> 
> I have postgresql 8.3.1 installed and pgsql and pdo_pgsql extensions
> doesn't get loaded with this rc version and also with latest snapshot
> 5.2.7-dev. With php 5.2.5 everything works fine on a windows xp sp2
> laptop and using the same php.ini file.
> 
> regards
> holo

The postgresl libs were upgraded however since you're using 8.3.1 there
shouldn't be any issues, but "doesn't get loaded" doesn't describe the
issue very well - do you have startup errors on? Could you please give
us the exact error? Also you'll need to see what version of the
postgresql client libs you have in your windows PATH  If you have older
client libs lying around the new pgsql extension will have a fit.
(Continue reading)

Holo | 1 May 03:15 2008
Picon

[PHP-DEV] Re: PHP 5.2.6RC5 windows build available

Elizabeth M Smith escreveu:
> Holo wrote:
>> Rob Richards escreveu:
>>> A little late to the party, but the windows build for PHP 5.2.6RC5 is
>>> finally available. Please test it as much as possible.
>>>
>>> http://pecl2.php.net/downloads/php-windows-builds/qa/php-5.2.6RC5-Win32.zip
>>>
>>> http://pecl2.php.net/downloads/php-windows-builds/qa/php-debug-pack-5.2.6RC5-Win32.zip
>>>
>>>
>>> The non-ts build will only be available for the release of 5.2.6
>>>
>>> Rob
>>>
>> Hi
>>
>> I have postgresql 8.3.1 installed and pgsql and pdo_pgsql extensions
>> doesn't get loaded with this rc version and also with latest snapshot
>> 5.2.7-dev. With php 5.2.5 everything works fine on a windows xp sp2
>> laptop and using the same php.ini file.
>>
>> regards
>> holo
> 
> The postgresl libs were upgraded however since you're using 8.3.1 there
> shouldn't be any issues, but "doesn't get loaded" doesn't describe the
> issue very well - do you have startup errors on? Could you please give
> us the exact error? Also you'll need to see what version of the
> postgresql client libs you have in your windows PATH  If you have older
(Continue reading)

Keryx Web | 1 May 11:45 2008
Picon

Re: [PHP-DEV] Return type hinting patch

Alain Williams skrev:

> Nice in some ways, except that it is different from the way that type hinting
> works in PHP5 classes - again: keep to one way of doing things.
> 
> ': RetType' might be possible, but it is very different from where type hints
> are given currently in PHP.
> 
> Stick with:
> 
> 	function int &myfunction(int &$param)
> 

Yes, on second thought I agree. "Keep to one way of doing things" is 
definitely sound advice from a teaching POV.

Lars Gunther

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

BuildSmart | 1 May 22:50 2008

Re: [PHP-DEV] OS X, enable embed problem, patch


On Apr 30, 2008, at 11:20 AM, Christopher Thompson wrote:

I don't want libphp.so as we are not using Apache.

The brief details are roughly as follows:
- we use lighthttpd for a web server

I have lighttpd running in OSX with PHP with quite a few extensions as well so it's either your configure flags, environment or both that are causing you problems.

- much of our site is in Php
- we are transitioning to Ruby
- we have a custom-written wrapper to allow Php to run inside of Ruby, to make the transition a little easier

Without knowing anything about your wrapper I can't comment on it's effectiveness or implementation but using the correct configure flags I'm able to generate a shared library of php without your patch so it has to be somehting your not doing or doing wrong.

You could have saved a lot of grief by posting your complete configure flag and details about your method of use


Now, this wrapper needs to link to php.  On Windows and Linux, that's easy.  But on OS X, if we end up with libphp5.so, the link step fails. With a dylib, though, the link step succeeds and life is good, if a little bit rainy.

It is very possible that we actually want a static build.  I'm new at nexopia and previous people who had tried this reported some problems, though this could have been on an unrelated matter.  On the other hand, ./configure --enable-embed=shared (or just --enable-embed) fails during the linking step as documented by the bug I linked to, 44462.

I freely admit to not being totally up to speed on OS X build environments.  Until last week, I just sort of assumed OS X used .so files for everything.  In other words, the problem here may be my expectations, and I would love to be educated on this matter.  Still, the patch I've attached, generating a dylib, does solve the specific problem I'm trying to solve.

Your patch doesn't give you the results your expecting.


While I was expecting "auto" tools to take care of the shared library issue, php-5.2.5 still seems to attempt to build an .so file on OS X, fails (with --enable-embed), and regardless, _I_ suspect should be generating a dylib for me anyway.

Becuase you provide no details  on how any of the software you are using was built I can only assume what you are trying to achieve is blurred by your lack of knowledge and understanding of achieving what you require.

Try using "--enable-fastcgi" instead of "--enable-embed" for lighttpd and also examine the help in configure, you will find that some flags conflict, while it may work in a particular OS this doesn't make it right.

Then rename php to php-fastcgi, copy php.ini to /etc/lighttpd-php.ini.

Assuming you used "--prefix= /usr/local/php" for php, put the following in lighttpd.conf you put:

#### fastcgi module
## read fastcgi.txt for more info
fastcgi.server = (".php" =>
(
( "socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/local/php/bin/php-fastcgi -c /etc/lighttpd-php.ini",
"min-procs" => 1,
"max-procs" => 4,
"max-load-per-proc" => 4,
"idle-timeout" => 20 
)
)
)



You can take a quick peek at http://daleenterprise.com:86/info.php , I'll leave it up for a couple of days.


BuildSmart wrote:
This is taken care of by "auto" tools.
If you are experiencing build issues of public releases then you're doing something wrong.
I build PHP for a living in OS X and I've encountered no build issues what-so-ever related to building with dylib linking but the resulting binary will (should) still be libphp.so because apache expects this.
If you need some help I can spare a few moments and examine your build environment and offer you some pointers/advice that should help you to develop better binary builds.
Out of curiosity, why are you enabling embedded in this manner, there are very few reason that PHP needs to be built this way and the environment and dependancies need to be established for the build to be successful.
When building for embedding purposes you really want a static build (libphp.a rather than libphp.so) so I'm having a hard time understanding what exactly it is you're trying to achieve.
 -- Dale
On Apr 29, 2008, at 19:14 PM, Christopher Thompson wrote:
Please be gentle, I have very little experience developing on OS X.  To be honest, the whole dylib thing seems messy and confusing to me, compared to the fairly straight-forward Linux style .so approach.


Expected behavior:
Able to configure and build on OS X with:
./configure --enable-embed

Actual behavior:

Suspected problem:
Trying to build .so instead of .dylib on OS X.

Suggested solution:
See patch below.  This makes it possible to do:
./configure --enable-embed=dylib
I did this instead of fixing --enable-embed=shared because the build process appears to be fundamentally different.

NOTE!  Once applying the patch, you need to do:
aclocal
autoconf
./configure --enable-embed=dylib

If you don't do aclocal to regenerate the necessary files, things break.


diff -urN php-5.2.5.clean/Makefile.global php-5.2.5/Makefile.global
--- php-5.2.5.clean/Makefile.global 2007-08-03 08:01:56.000000000 -0600
+++ php-5.2.5/Makefile.global 2008-04-29 16:44:36.000000000 -0600
<at> <at> -17,6 +17,10 <at> <at>
  $(LIBTOOL) --mode=link $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -rpath $(phptempdir) $(EXTRA_LDFLAGS) $(LDFLAGS) $(PHP_RPATHS) $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $ <at>
  - <at> $(LIBTOOL) --silent --mode=install cp $ <at> $(phptempdir)/$ <at> >/dev/null 2>&1

+libphp$(PHP_MAJOR_VERSION).dylib: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
+ $(LIBTOOL) --mode=link $(CC) -dynamiclib -install_name $(INSTALL_ROOT)$(prefix)/lib/$ <at> -current_version $(PHP_VERSION) -compatibility_version $(PHP_MAJOR_VERSION) -undefined dynamic_lookup $(PHP_RPATHS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $ <at>
+ - <at> $(LIBTOOL) --silent --mode=install cp $ <at> $(phptempdir)/$ <at> >/dev/null 2>&1
+
 libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
  $(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $ <at> && cp $ <at> libs/libphp$(PHP_MAJOR_VERSION).so

diff -urN php-5.2.5.clean/acinclude.m4 php-5.2.5/acinclude.m4
--- php-5.2.5.clean/acinclude.m4 2007-08-20 08:28:45.000000000 -0600
+++ php-5.2.5/acinclude.m4 2008-04-29 16:44:44.000000000 -0600
<at> <at> -799,6 +799,15 <at> <at>
 ])

 dnl
+dnl PHP_BUILD_DYLIB
+dnl
+AC_DEFUN([PHP_BUILD_DYLIB],[
+  PHP_BUILD_PROGRAM
+  OVERALL_TARGET=libphp[]$PHP_MAJOR_VERSION[.dylib]
+  php_build_target=static
+])
+
+dnl
 dnl PHP_BUILD_BUNDLE
 dnl
 AC_DEFUN([PHP_BUILD_BUNDLE],[
<at> <at> -885,6 +894,7 <at> <at>
   case "$2" in
   static[)] PHP_BUILD_STATIC;;
   shared[)] PHP_BUILD_SHARED;;
+  dylib[)]  PHP_BUILD_DYLIB;;
   bundle[)] PHP_BUILD_BUNDLE;;
   program[)] PHP_BUILD_PROGRAM($5);;
   esac
diff -urN php-5.2.5.clean/configure.in php-5.2.5/configure.in
--- php-5.2.5.clean/configure.in 2007-11-08 07:44:11.000000000 -0600
+++ php-5.2.5/configure.in 2008-04-29 16:44:52.000000000 -0600
<at> <at> -252,6 +252,7 <at> <at>
 dnl paths to the targets are relative to the build directory
 SAPI_SHARED=libs/libphp[]$PHP_MAJOR_VERSION[.]$SHLIB_DL_SUFFIX_NAME
 SAPI_STATIC=libs/libphp[]$PHP_MAJOR_VERSION[.a]
+SAPI_DYLIB=libs/libphp[]$PHP_MAJOR_VERSION[.]$SHLIB_SUFFIX_NAME
 SAPI_LIBTOOL=libphp[]$PHP_MAJOR_VERSION[.la]

 PHP_CONFIGURE_PART(Configuring SAPI modules)
diff -urN php-5.2.5.clean/sapi/embed/config.m4 php-5.2.5/sapi/embed/config.m4
--- php-5.2.5.clean/sapi/embed/config.m4 2007-07-11 17:20:36.000000000 -0600
+++ php-5.2.5/sapi/embed/config.m4 2008-04-29 16:45:06.000000000 -0600
<at> <at> -4,7 +4,7 <at> <at>

 PHP_ARG_ENABLE(embed,,
 [  --enable-embed[=TYPE]   EXPERIMENTAL: Enable building of embedded SAPI library
-                          TYPE is either 'shared' or 'static'. [TYPE=shared]], no, no)
+                          TYPE is 'shared', 'static', or 'dylib'. [TYPE=shared]], no, no)

 AC_MSG_CHECKING([for embedded SAPI library support])

<at> <at> -18,6 +18,10 <at> <at>
       PHP_EMBED_TYPE=static
       INSTALL_IT="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(prefix)/lib; \$(INSTALL) -m 0644 $SAPI_STATIC \$(INSTALL_ROOT)\$(prefix)/lib"
       ;;
+    dylib)
+      PHP_EMBED_TYPE=dylib
+      INSTALL_IT="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(prefix)/lib; \$(INSTALL) -m 0644 $SAPI_DYLIB \$(INSTALL_ROOT)\$(prefix)/lib"
+      ;;
     *)
       PHP_EMBED_TYPE=no
       ;;


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


-- Dale



-- Dale



Christopher Thompson | 1 May 23:28 2008

Re: [PHP-DEV] OS X, enable embed problem, patch

Okay, let me try to be explicit here.  If I am leaving out any important 
information, please just ask.

Environment:
OS X
uname -a:
Darwin host-29.dev.office.nexopia.com 9.2.2 Darwin Kernel Version 9.2.2: 
Tue Mar  4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386
with php-5.2.5.

What I want:
A php library that can be linked in to another executable (a 
custom-written executable, described briefly below) via -lphp5 
command-line flag on OS X.

Why the FastCGI option isn't appropriate for us:
We are trying to transition from Php to Ruby and want a way to call Php 
code from inside of Ruby.  To do this, we have a custom-written 
executable "wrapper" to directly call Php.

What I expect will cause this to happen:
./configure --enable-embed --prefix=/nexopia/packages/Php
(or --enable-embed=shared)
This is exactly the configuration flags we use.

What actually happens:
This works on Linux, Windows.  On OS X, this configuration fails, as 
described in the bug report, 44462.

What happens with the patch I included:
Using ./configure --enable-embed=dylib --prefix=/nexopia/packages/Php 
results in a successful build.  The resulting libphp5.dylib allows us to 
build the other executable and use -lphp5 to link in the Php lib.

What I THINK would happen with a .so instead of .dylib:
Would not be able to link our executable using -lphp5 on OS X.

Again, if I have missed out any useful information, please let me know. 
  I'm not deliberately hiding anything.

BuildSmart wrote:
> 
> On Apr 30, 2008, at 11:20 AM, Christopher Thompson wrote:
> 
>> I don't want libphp.so as we are not using Apache.
>>
>> The brief details are roughly as follows:
>> - we use lighthttpd for a web server
> 
> I have lighttpd running in OSX with PHP with quite a few extensions as 
> well so it's either your configure flags, environment or both that are 
> causing you problems.
> 
>> - much of our site is in Php
>> - we are transitioning to Ruby
>> - we have a custom-written wrapper to allow Php to run inside of Ruby, 
>> to make the transition a little easier
> 
> Without knowing anything about your wrapper I can't comment on it's 
> effectiveness or implementation but using the correct configure flags 
> I'm able to generate a shared library of php without your patch so it 
> has to be somehting your not doing or doing wrong.
> 
> You could have saved a lot of grief by posting your complete configure 
> flag and details about your method of use
> 
>>
>> Now, this wrapper needs to link to php.  On Windows and Linux, that's 
>> easy.  But on OS X, if we end up with libphp5.so, the link step fails. 
>> With a dylib, though, the link step succeeds and life is good, if a 
>> little bit rainy.
>>
>> It is very possible that we actually want a static build.  I'm new at 
>> nexopia and previous people who had tried this reported some problems, 
>> though this could have been on an unrelated matter.  On the other 
>> hand, ../configure --enable-embed=shared (or just --enable-embed) 
>> fails during the linking step as documented by the bug I linked to, 44462.
>>
>> I freely admit to not being totally up to speed on OS X build 
>> environments.  Until last week, I just sort of assumed OS X used .so 
>> files for everything.  In other words, the problem here may be my 
>> expectations, and I would love to be educated on this matter.  Still, 
>> the patch I've attached, generating a dylib, does solve the specific 
>> problem I'm trying to solve.
> 
> Your patch doesn't give you the results your expecting.
> 
>>
>> While I was expecting "auto" tools to take care of the shared library 
>> issue, php-5.2.5 still seems to attempt to build an .so file on OS X, 
>> fails (with --enable-embed), and regardless, _I_ suspect should be 
>> generating a dylib for me anyway.
> 
> Becuase you provide no details  on how any of the software you are using 
> was built I can only assume what you are trying to achieve is blurred by 
> your lack of knowledge and understanding of achieving what you require.
> 
> Try using "--enable-fastcgi" instead of "--enable-embed" for lighttpd 
> and also examine the help in configure, you will find that some flags 
> conflict, while it may work in a particular OS this doesn't make it right.
> 
> Then rename php to php-fastcgi, copy php.ini to /etc/lighttpd-php.ini.
> 
> Assuming you used "--prefix= /usr/local/php" for php, put the following 
> in lighttpd.conf you put:
> 
> #### fastcgi module
> ## read fastcgi.txt for more info
> fastcgi.server = (".php" =>
> (
> ( "socket" => "/tmp/php-fastcgi.socket",
> "bin-path" => "/usr/local/php/bin/php-fastcgi -c /etc/lighttpd-php.ini",
> "min-procs" => 1,
> "max-procs" => 4,
> "max-load-per-proc" => 4,
> "idle-timeout" => 20 
> )
> )
> )
> 
> 
> 
> You can take a quick peek at http://daleenterprise.com:86/info.php , 
> I'll leave it up for a couple of days.
> 
>>
>> BuildSmart wrote:
>>> This is taken care of by "auto" tools.
>>> If you are experiencing build issues of public releases then you're 
>>> doing something wrong.
>>> I build PHP for a living in OS X and I've encountered no build issues 
>>> what-so-ever related to building with dylib linking but the resulting 
>>> binary will (should) still be libphp.so because apache expects this.
>>> If you need some help I can spare a few moments and examine your 
>>> build environment and offer you some pointers/advice that should help 
>>> you to develop better binary builds.
>>> Out of curiosity, why are you enabling embedded in this manner, there 
>>> are very few reason that PHP needs to be built this way and the 
>>> environment and dependancies need to be established for the build to 
>>> be successful.
>>> When building for embedding purposes you really want a static build 
>>> (libphp.a rather than libphp.so) so I'm having a hard time 
>>> understanding what exactly it is you're trying to achieve.
>>>  -- Dale
>>> On Apr 29, 2008, at 19:14 PM, Christopher Thompson wrote:
>>>> Please be gentle, I have very little experience developing on OS X.  
>>>> To be honest, the whole dylib thing seems messy and confusing to me, 
>>>> compared to the fairly straight-forward Linux style .so approach.
>>>>
>>>>
>>>> Expected behavior:
>>>> Able to configure and build on OS X with:
>>>> ./configure --enable-embed
>>>>
>>>> Actual behavior:
>>>> http://bugs.php.net/bug.php?id=44462
>>>>
>>>> Suspected problem:
>>>> Trying to build .so instead of .dylib on OS X.
>>>>
>>>> Suggested solution:
>>>> See patch below.  This makes it possible to do:
>>>> ./configure --enable-embed=dylib
>>>> I did this instead of fixing --enable-embed=shared because the build 
>>>> process appears to be fundamentally different.
>>>>
>>>> NOTE!  Once applying the patch, you need to do:
>>>> aclocal
>>>> autoconf
>>>> ./configure --enable-embed=dylib
>>>>
>>>> If you don't do aclocal to regenerate the necessary files, things break.
>>>>
>>>>
>>>> diff -urN php-5.2.5.clean/Makefile.global php-5.2.5/Makefile.global
>>>> --- php-5.2.5.clean/Makefile.global 2007-08-03 08:01:56.000000000 -0600
>>>> +++ php-5.2.5/Makefile.global 2008-04-29 16:44:36.000000000 -0600
>>>>  <at>  <at>  -17,6 +17,10  <at>  <at> 
>>>>   $(LIBTOOL) --mode=link $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -rpath 
>>>> $(phptempdir) $(EXTRA_LDFLAGS) $(LDFLAGS) $(PHP_RPATHS) 
>>>> $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) 
>>>> -o $ <at> 
>>>>   - <at> $(LIBTOOL) --silent --mode=install cp $ <at>  $(phptempdir)/$ <at>  
>>>> >/dev/null 2>&1
>>>>
>>>> +libphp$(PHP_MAJOR_VERSION).dylib: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
>>>> + $(LIBTOOL) --mode=link $(CC) -dynamiclib -install_name 
>>>> $(INSTALL_ROOT)$(prefix)/lib/$ <at>  -current_version $(PHP_VERSION) 
>>>> -compatibility_version $(PHP_MAJOR_VERSION) -undefined 
>>>> dynamic_lookup $(PHP_RPATHS) $(PHP_GLOBAL_OBJS:.lo=.o) 
>>>> $(PHP_SAPI_OBJS:.lo=.o) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $ <at> 
>>>> + - <at> $(LIBTOOL) --silent --mode=install cp $ <at>  $(phptempdir)/$ <at>  
>>>> >/dev/null 2>&1
>>>> +
>>>>  libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS) 
>>>> $(PHP_SAPI_OBJS)
>>>>   $(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) 
>>>> $(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) 
>>>> $(PHP_SAPI_OBJS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) 
>>>> $(ZEND_EXTRA_LIBS) -o $ <at>  && cp $ <at>  libs/libphp$(PHP_MAJOR_VERSION).so
>>>>
>>>> diff -urN php-5.2.5.clean/acinclude.m4 php-5.2.5/acinclude.m4
>>>> --- php-5.2.5.clean/acinclude.m4 2007-08-20 08:28:45.000000000 -0600
>>>> +++ php-5.2.5/acinclude.m4 2008-04-29 16:44:44.000000000 -0600
>>>>  <at>  <at>  -799,6 +799,15  <at>  <at> 
>>>>  ])
>>>>
>>>>  dnl
>>>> +dnl PHP_BUILD_DYLIB
>>>> +dnl
>>>> +AC_DEFUN([PHP_BUILD_DYLIB],[
>>>> +  PHP_BUILD_PROGRAM
>>>> +  OVERALL_TARGET=libphp[]$PHP_MAJOR_VERSION[.dylib]
>>>> +  php_build_target=static
>>>> +])
>>>> +
>>>> +dnl
>>>>  dnl PHP_BUILD_BUNDLE
>>>>  dnl
>>>>  AC_DEFUN([PHP_BUILD_BUNDLE],[
>>>>  <at>  <at>  -885,6 +894,7  <at>  <at> 
>>>>    case "$2" in
>>>>    static[)] PHP_BUILD_STATIC;;
>>>>    shared[)] PHP_BUILD_SHARED;;
>>>> +  dylib[)]  PHP_BUILD_DYLIB;;
>>>>    bundle[)] PHP_BUILD_BUNDLE;;
>>>>    program[)] PHP_BUILD_PROGRAM($5);;
>>>>    esac
>>>> diff -urN php-5.2.5.clean/configure.in php-5.2.5/configure.in
>>>> --- php-5.2.5.clean/configure.in 2007-11-08 07:44:11.000000000 -0600
>>>> +++ php-5.2.5/configure.in 2008-04-29 16:44:52.000000000 -0600
>>>>  <at>  <at>  -252,6 +252,7  <at>  <at> 
>>>>  dnl paths to the targets are relative to the build directory
>>>>  SAPI_SHARED=libs/libphp[]$PHP_MAJOR_VERSION[.]$SHLIB_DL_SUFFIX_NAME
>>>>  SAPI_STATIC=libs/libphp[]$PHP_MAJOR_VERSION[.a]
>>>> +SAPI_DYLIB=libs/libphp[]$PHP_MAJOR_VERSION[.]$SHLIB_SUFFIX_NAME
>>>>  SAPI_LIBTOOL=libphp[]$PHP_MAJOR_VERSION[.la]
>>>>
>>>>  PHP_CONFIGURE_PART(Configuring SAPI modules)
>>>> diff -urN php-5.2.5.clean/sapi/embed/config.m4 
>>>> php-5.2.5/sapi/embed/config.m4
>>>> --- php-5.2.5.clean/sapi/embed/config.m4 2007-07-11 
>>>> 17:20:36.000000000 -0600
>>>> +++ php-5.2.5/sapi/embed/config.m4 2008-04-29 16:45:06.000000000 -0600
>>>>  <at>  <at>  -4,7 +4,7  <at>  <at> 
>>>>
>>>>  PHP_ARG_ENABLE(embed,,
>>>>  [  --enable-embed[=TYPE]   EXPERIMENTAL: Enable building of 
>>>> embedded SAPI library
>>>> -                          TYPE is either 'shared' or 'static'. 
>>>> [TYPE=shared]], no, no)
>>>> +                          TYPE is 'shared', 'static', or 'dylib'. 
>>>> [TYPE=shared]], no, no)
>>>>
>>>>  AC_MSG_CHECKING([for embedded SAPI library support])
>>>>
>>>>  <at>  <at>  -18,6 +18,10  <at>  <at> 
>>>>        PHP_EMBED_TYPE=static
>>>>        INSTALL_IT="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(prefix)/lib; 
>>>> \$(INSTALL) -m 0644 $SAPI_STATIC \$(INSTALL_ROOT)\$(prefix)/lib"
>>>>        ;;
>>>> +    dylib)
>>>> +      PHP_EMBED_TYPE=dylib
>>>> +      INSTALL_IT="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(prefix)/lib; 
>>>> \$(INSTALL) -m 0644 $SAPI_DYLIB \$(INSTALL_ROOT)\$(prefix)/lib"
>>>> +      ;;
>>>>      *)
>>>>        PHP_EMBED_TYPE=no
>>>>        ;;
>>>>
>>>>
>>>> -- 
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>>
>>> -- Dale
>>
>>
> 
> -- Dale
> 
> 
> 

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Dhiru Pandey | 2 May 03:09 2008
Picon

[PHP-DEV] Re: Help: call_user_function() core dumps

Thanks Johannes,

Your suggestions were spot on. Thanks again - Dhiru

Johannes Schlüter wrote:
> Hi,
>
> On Wed, 2008-04-30 at 09:52 -0700, Dhiru Pandey wrote:
>   
>> I am new to PHP extension writing and embedding. Following the book from
>> Sara Goleman - Extending and Embedding PHP (Developer's Library)
>> I wrote the following program based on her example in Chap. 20
>>
>> ===================================================================
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> #include <sapi/embed/php_embed.h>
>>
>> int main(int argc, char** argv) {
>>       PHP_EMBED_START_BLOCK(argc, argv);
>>
>>     zval* args[2];
>>     zval funcname;
>>     zval input_str;
>>     zval count;
>>     zval retval;
>>     char* ans;
>>       ZVAL_STRING(&funcname, "str_repeat", 0);
>>     args[0] = &input_str;
>>     args[1] = &count;
>>     
>
> You have to use emalloc'ed memory for (basically) everything you give to
> the engine and no pointers to local variables else the engine tries to
> free these local variables.
>
> johannes
>
>   
Marcus Boerger | 2 May 12:03 2008
Picon
Picon

Re: [PHP-DEV] Calling a class constructor

Hello Antony, Johannes,

seeing this thread I agree. So that makes the list: PCRE, Reflection, SPL.
Johannes?

Wednesday, April 30, 2008, 9:22:19 PM, you wrote:

> On 30.04.2008 23:17, Lars Strojny wrote:
>> Hi all, esp. Johannes,
>> 
>> Am Mittwoch, den 30.04.2008, 13:05 -0400 schrieb Sam Barrow:
>> [...]
>>> Still, that just seems unnecessary, I usually compile without the
>>> reflection stuff because i never use it. I'd like to be able to use this
>>> like call_user_func, I'm pretty much doing the same thing.
>>
>> Oh, good hint. As the we already have hard enabling changes (SPL, PCRE)
>> in 5.3, shouldn't we force enabling reflections?

> Yes, I believe a feature like this should be always enabled, 
> as it's actually a part of the language/engine.

> -- 
> Wbr, 
> Antony Dovgal

Best regards,
 Marcus

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Johannes Schlüter | 2 May 13:29 2008
Picon
Picon

Re: [PHP-DEV] Calling a class constructor


On Fri, 2008-05-02 at 12:03 +0200, Marcus Boerger wrote:
> Hello Antony, Johannes,
> 
> seeing this thread I agree. So that makes the list: PCRE, Reflection, SPL.
> Johannes?

I was under the impression that was already the case for Reflection, so
I don't mind.

johannes

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Jonathan Bond-Caron | 2 May 18:52 2008

[PHP-DEV] Float comparison

Hi,

I'm new to the PHP internals list and I'm posting an issue I'm sure has been
mentioned before -- float comparison

I'd like to know if there are reasons not to change the default behavior
when comparing floats.

i.e. This would seem logical to me:

                $test = 19.6*100;

                if((float)(string)$test == (double)1960)

                                echo "GOOD BEHAVIOR";

                // Implicitely convert the float to string then float (en_US
locale)

                if($test == (double)1960)

                                echo "THIS SHOULD PASS by casting
(float)(string)$test internally...";

                else

                                echo "NOT GOOD BEHAVIOR";

                // Exact comparison would still fail

                if($test !== (double)1960)

                                echo "GOOD BEHAVIOR";

Any reason why $test == (double)1960 should fail? I realized we are
comparing two floats, but couldn't php internally convert to string then
float - for the non strict (===) case  

Thanks

J.P. Cummins | 2 May 19:07 2008

[PHP-DEV] CVS Account Request: jpcummins

Make Phalanger and DLR version of PHP that is compliant with all PHP standards and unit test(s).

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Gmane