Re: [PHP-DEV] PHP building on Linux: A question on configurescript!

[Ananth Kesari]

Hi Jean,

Thanks for your elaborate reply with the work around. I also got the files you sent. 
We will try this and get back to you if we have any issues.

Thanks,
Ananth.

>>> Jean-Michel Dault <[EMAIL PROTECTED]> 01/06/03 10:19PM >>>
Le lun 06/01/2003 à 07:24, Ananth Kesari a écrit :
> What we are looking for is to find out whether or not the current
> autotool input files of PHP support the ability to produce a spearate
> phplib.l and the appropriate "main" module - one for Apache 1.3, one for
> Apache 2.0, one for command line etc. each of which can use the same
> phplib.l ?
> 
> We tried to figure this out on Linux, but it appears that this seems
> not to be supported. Are we correct in our findings? Or is there really
> a way of doing the above of having different shared modules?

It is not supported officially, but there's a way to do it.

As I promised a couple of days ago, here is a solution that works for
me, though it's not very pretty. I could of course modify the m4 files,
but it's left as an exercise to the readers of this list ;-) 

Here is the procedure:
1) Patch the makefile.global and configure script using the
"shared-patch" I enclosed in this mail. This will compile a shared
library containing the PHP core, and will patch the CGI and CLI version
so they use this library.

2) do ./configure, with all the options that you want, but do *not* use
the --with-apache or --with-apxs options. You want to compile first the
CGI and CLI binaries and the shared library.

3) do a make, but do not do a make install yet.

4) To compile the Apache 1.3 module, use the enclosed "do1.3" script.
   If your Apache environment is setup correctly, you will have a
   libphp4.so in the sapi/apache directory. This is the Apache DSO that
   you'll need to copy in your Apache 1.3 modules directory.

5) To compile the Apache 2.0 module, use the enclosed "do2.0" script.
   If your Apache environment is setup correctly, you will have a 
   mod_php4.so in the sapi/apache2filter/.libs directory. This is the
   Apache 2.0 DSO that you'll need to copy in your Apache 2.0 modules
   directory.

   Please note that to be able to compile both Apache 1.3 and Apache 2.0
   modules, you need two different apxs binaries and two different
   apache include directories. I personnaly use the following dirs:
   Apache 1.3: /usr/sbin/apxs and /usr/include/apache for 1.3 
   Apache 2.0: /usr/sbin/apxs2 and /usr/include/apache2

6) Finally, place the libphp_common library in /usr/lib
   mv libphp_common.so libphp_common.so.430
   ln -s libphp_common.so.430 libphp_common
   cp libphp_common* /usr/lib

7) Now do a "make install", "make install-cli"

8) Finally, you can install sapi/cgi/php to whatever location/name you
   want that is different from the CLI version.

9) You'll still need to tweak your httpd.conf to put the required
   LoadModule, AddModule and AddType directives.

10) Or better yet, install Mandrake Linux and have it already
pre-configured ;-)


Regards,

Jean-Michel Dault
Apache/PHP Packager
Mandrake Linux



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

Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[Brian Moon]

| > >I don't recall anyone saying
| > >it would be BC either, but I could be wrong.
| > 
| > You're wrong.
| > 
| > Of course, I could be too.
| >
| but you're not.  so its ok...
| 


So current PHP4 classes will still work in ZE2?

Brian.

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

Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[Leon Atkinson]

> Any good links you could throw my way describing proposed changes?

There are archives of the Zend Engine 2 list at zend.com:
http://www.zend.com/lists.php

There is one big change with objects that will break BC.  Objects pass by
reference instead of value, both for function calls and assignments.  For
example:

name = 'C';
}

$a = new a;
$b = $a;

$a->name = "A";
print($a->name);
$b->name = "B";
print($a->name);
c($a);
print($a->name);
?>

In ZE1 you get "AAA". In ZE2 you get "ABC".

Leon

---
Leon Atkinson 



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

Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[Sterling Hughes]

> So code should be backwards compatible?  Very nice.
> 
> Any good links you could throw my way describing proposed changes?
>

never said that.  but constructors will be backwards compatible.

changes are available in the ZendEngine2 cvs repository.

-sterling

> Thanks guys.
> 
> John
> 
> Sterling Hughes said:
> >> On Monday, January 6, 2003, at 09:48  PM, Brian Moon wrote:
> >>
> >> >From what I understand, all OO code will have to be modified for
> >> PHP5. Constructors for example and no longer named the same as the
> >> class  name.
> >> >That alone means every class must be changed.  I don't recall anyone
> >> saying
> >> >it would be BC either, but I could be wrong.
> >>
> >> You're wrong.
> >>
> >> Of course, I could be too.
> >>
> > but you're not.  so its ok...
> >
> > :)
> >
> > -Sterling
> >
> >>
> >> --
> >> PHP Development Mailing List 
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

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

Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[John Wells]

So code should be backwards compatible?  Very nice.

Any good links you could throw my way describing proposed changes?

Thanks guys.

John

Sterling Hughes said:
>> On Monday, January 6, 2003, at 09:48  PM, Brian Moon wrote:
>>
>> >From what I understand, all OO code will have to be modified for
>> PHP5. Constructors for example and no longer named the same as the
>> class  name.
>> >That alone means every class must be changed.  I don't recall anyone
>> saying
>> >it would be BC either, but I could be wrong.
>>
>> You're wrong.
>>
>> Of course, I could be too.
>>
> but you're not.  so its ok...
>
> :)
>
> -Sterling
>
>>
>> --
>> PHP Development Mailing List 
>> To unsubscribe, visit: http://www.php.net/unsub.php




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

Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[Sterling Hughes]

> On Monday, January 6, 2003, at 09:48  PM, Brian Moon wrote:
> 
> >From what I understand, all OO code will have to be modified for PHP5.
> >Constructors for example and no longer named the same as the class 
> >name.
> >That alone means every class must be changed.  I don't recall anyone 
> >saying
> >it would be BC either, but I could be wrong.
> 
> You're wrong.
> 
> Of course, I could be too.
>
but you're not.  so its ok...

:)

-Sterling

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

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

Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[George Schlossnagle]

On Monday, January 6, 2003, at 09:48  PM, Brian Moon wrote:


From what I understand, all OO code will have to be modified for PHP5.
Constructors for example and no longer named the same as the class 
name.
That alone means every class must be changed.  I don't recall anyone 
saying
it would be BC either, but I could be wrong.

You're wrong.

Of course, I could be too.


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

Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[Brian Moon]

>From what I understand, all OO code will have to be modified for PHP5.
Constructors for example and no longer named the same as the class name.
That alone means every class must be changed.  I don't recall anyone saying
it would be BC either, but I could be wrong.

Brian Moon
-
dealnews.com
-
phorum.org

- Original Message -
From: "John Wells" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 7:03 PM
Subject: [PHP-DEV] Designing for PHP4 with PHP5 in mind...


| I'm preparing for a project in which I'll be porting and redesigning a
| large, ugly Visual Basic/Sql Server app to a PHP/Mysql or Postgresql based
| web application.
|
| I'd like to code in a way that will be at the same time easily ported to
| PHP5 and that will take advantage of PHP5's new object handling
| efficiencies.  I've read varying reports of whether syntax will be
| different.
|
| Is there anything I should watch for, add, or specifically avoid while
| coding this application to make the transition as easy as possible?
|
| Thanks!
| John
|
|
|
|
|
|
|
|
| --
| PHP Development Mailing List 
| To unsubscribe, visit: http://www.php.net/unsub.php
|
|
|


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

[PHP-DEV] Designing for PHP4 with PHP5 in mind...

[John Wells]

I'm preparing for a project in which I'll be porting and redesigning a
large, ugly Visual Basic/Sql Server app to a PHP/Mysql or Postgresql based
web application.

I'd like to code in a way that will be at the same time easily ported to
PHP5 and that will take advantage of PHP5's new object handling
efficiencies.  I've read varying reports of whether syntax will be
different.

Is there anything I should watch for, add, or specifically avoid while
coding this application to make the transition as easy as possible?

Thanks!
John








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

[PHP-DEV] Should I fix this?

[Rickard Andersson]

My only contribution to PHP thus far is the following bug report/feature
request (#18052):

getimagesize() blindly trusts the width and height specified in the header
of gifs. You can just hexedit the file and set the width and height to any
value and getimagesize() will believe that is the "true size" of the image.
Even worse - Internet Explorer ignores the width and height in the header
and thus it is possible to, for instance, upload a much larger image in an
upload form that uses getimagesize() than what is allowed. I believe
getimagesize() should just skip the header and read the size from the
beginning of the "Image Block".

I'd be glad to write a patch for image.c (function php_handle_gif()), but I
though I should ask you guys first. I wouldn't want to do it in vain. As it
is now I've got PHP code that checks this for me to prevent "malicious"
users from uploading huge avatars in my forum software.

/Rickard



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

[PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version

[Joseph Tate]

Well, according to my highly technical methods of deduction (fprintf(stderr,
"Inside sapi_shutdown");)  sapi_shutdown is never called when serving a PHP
request when served using mod4_php under Apache.  This is because the
shutdown_wrapper never gets initialized as a cleanup function.  This because
the php_init_handler is never called, and this happens for some reason
undivinable by me.  Perhaps it should be used, and we should execute regular
shutdown functions there, and proceed to use php_request_shutdown in the way
it was used prior to php 4.1.x i.e. after the connection has closed (on
apache anyway) and while PHP is still in memory.  We'll get the added
benefit of (on Apache systems anyway) a significant performance gain as the
cleanup phase happens without the client having to wait for it.

Here is my vision based on my understanding of the inner workings of PHP.

There are at least four types of shutdown functions in PHP (not including
extensions):
PHP space (identified by the use of register_shutdown_function)
module_shutdown (called when a module is to clean up after itself)
sapi_shutdown (not used under many sapi implementations)
php_shutdown
there may also be zend and tsrm shutdown functions.

php_shutdown seems to always be a call to shutdown wheras the remainder are
called when shutdown occurs.  Thus the cleanup/shutdown routines should be
called in this order:

main
init
load and run PHP script
call sapi_shutdown
which calls module_shutdown on all used modules
and then executes register_shutdown_functions
and then calls php_request_shutdown in a server specific manner (in 
apache
as a cleanup_function after the http communication has terminated)
which (under platforms that support it) executes
register_offline_functions
before cleaning up PHP and freeing memory.

SAPI was developed for abstracting the server, but it seems that instead it
has been worked around rather than extended for the individual servers.  I
speak in generalizations, but that's what it looks like.  In my book, all
php internal functions should be called through the appropriate SAPI
functions, which are called by a main function for each sapi implementation.
There is too much deviation from this, thereby crippling SAPI.  Either use
it or cut it out completly.

These changes are too large for a minor version release, i.e. 4.3.1, but
perhaps for 4.4/5.0?  I'd be willing to put some time into reworking the
SAPI system.


> -Original Message-
> From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 31, 2002 4:21 AM
> To: Joseph Tate
> Cc: Php-Dev List; Jason Priebe
> Subject: RE: [PATCH]apache_register_shutdown_function final version
>
>
> As you can see in bug #15209, the change that introduced this problem was
> that we started calling php_request_shutdown() in apache_module_main(),
> prior to calling it from php_apache_request_shutdown().  So, the place to
> put it is clearly php_apache_request_shutdown(), where it used to
> be called
> before.
>
> The problem is by the time you would get to
> php_apache_request_shutdown(),
> the per-request memory manager is already deactivated, so any emalloc()'d
> memory you may have is already freed.  I'm not sure how to tackle
> this in a
> server independent way...
>
> Zeev
>
> At 21:55 30/12/2002, Joseph Tate wrote:
> >That's no good.  If I remove the sapi_close stuff, and try to execute the
> >shutdown functions in php_apache_request_shutdown() all I get is stuff in
> >the error log listing the "leaked" memory.  The requested
> function does not
> >get executed.
> >
> >Joseph
> >
> > > -Original Message-
> > > From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, December 30, 2002 1:57 PM
> > > Subject: RE: [PATCH]apache_register_shutdown_function final version
> > >
> > >
> > > Try looking at php_apache_request_shutdown() in mod_php4.c.  It's
> > > our pool
> > > destructor.
> > >
> > > Zeev
>
>
>


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

[PHP-DEV] CVS Account Request: nmee

[Nils Magnus Englund]

I'd like to contribute to the PHP project by translating the manual (at least parts of 
it) to Norwegian.

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

Re: [PHP-DEV] CGI and CLI [packaging issues]

[Philip Olson]

> This goes with the PHP source approach:
> By default, "configure/make/make install" compiles the CGI interface,
> and then you have to "make install-cli" to get the CLI.
> 
> We just replace the "make install-cli" by "urpmi/apt-get php-cli".

Just FYI, 'make install-cli' is not the only way to
install the CLI there, 'make install' may put it 
there too.  For example:

  'make install' copies CLI to {prefix}/bin/php
  ./configure --with-apxs

  'make install' copies CGI to {prefix}/bin/php
  ./configure --enable-cli

  'make install' copies CGI to {prefix}/bin/php
  ./configure

This is because both --enable-cgi and --enable-cli
are defaults.  If one specifies a module SAPI, such
as apxs, then CLI is copied as 'php' because
--disable-cgi is implicitly called.  This manual
entry explains this further:

  http://www.php.net/features.commandline

This email is for informational purposes only, I do
not agree or disagree with your proposal as I wouldn't
touch this with a large stick but just wanted to clear 
up any possible misconceptions :)

Regards,
Philip



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

[PHP-DEV] php 4.3.0 ext/oci8 -- OCI_SHARED patch

[Levi Dixon]

For review:

I've modified the following files to allow for use of OCI_SHARED in ext/oci8
module if OCI8_VERSION >= 8.1, which will provide memory savings by sharing
connection and statement data (refer to
http://www.csee.umbc.edu/help/oracle8/server.815/a67846/basics.htm; search
for "Shared Data Mode") between connections and statments respectively.  I
only have access to ext/oci8, so I can't check this in:

configure
main/php_config.h.in
ext/oci8/config.m4
ext/oci8/oci8.c

Note: I'm not familiar enough with the windows distribution to add the mod
there.

See new files at: http://www.vgsp.com/levi/

Please advise.

-


diff configure
49562a49563,49570
>   OCI8_SHARED_MODE_SUPPORTED=`expr $OCI8_VERSION \>= 8.1`
>
>   if test "$OCI8_SHARED_MODE_SUPPORTED" = "1"; then
>   cat >> confdefs.h <<\EOF
> #define HAVE_OCI8_SHARED_MODE 1
> EOF
>   fi
>

diff main/php_config.h.in
1933a1934,1936
> #undef HAVE_OCI8_SHARED_MODE
>
> /*   */

diff ext/oci8/config.m4
74a75
>   AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ])

diff ext/oci8/oci8.c
465a466,475
> #ifdef HAVE_OCI8_SHARED_MODE
>
> #ifdef WITH_COLLECTIONS
> #define PHP_OCI_INIT_MODE OCI_SHARED | OCI_OBJECT
> #else
> #define PHP_OCI_INIT_MODE OCI_SHARED
> #endif
>
> #else
>
471a482,483
> #endif
>



Levi Dixon
Tech. Lead; Sr. Developer
Community Connect, Inc.
149 5th Ave, Floor 10
New York, NY  10010
212-505-7511 x349
[EMAIL PROTECTED]
[EMAIL PROTECTED]



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

Re: [PHP-DEV] ZE2 dev snaps

[Stephan Seidt]

At least ./buildconf with --ZendEngine2 did never work for me. ;)
I also did cvs co ZendEngine2 in php4 cvstree root.

Mark J. Hershenson wrote:

Hi all,

I know there are "Win32+ZE2 Package" snapshots on snaps.php.net, but I don't
believe I've read why there isn't a ZE2 source code snapshot for everyone
else. Checking out the source with CVS may not be the world's most difficult
practice, but automating that process likely isn't either. ;)

Is there a timeline for this, or is this being intentionally kept off the
radar?

--  mjh





--
When ipv6 and tcpa are there.. When this Palladium server wrecks..
I won't be able to drink my coffe then!


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

[PHP-DEV] ZE2 dev snaps

[Mark J. Hershenson]

Hi all,

I know there are "Win32+ZE2 Package" snapshots on snaps.php.net, but I don't
believe I've read why there isn't a ZE2 source code snapshot for everyone
else. Checking out the source with CVS may not be the world's most difficult
practice, but automating that process likely isn't either. ;)

Is there a timeline for this, or is this being intentionally kept off the
radar?

--  mjh


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

Re: [PHP-DEV] PHP building on Linux: A question on configure script!

[Jean-Michel Dault]

Oops.. I forgot the files... Here they are!

Le lun 06/01/2003 à 12:49, Jean-Michel Dault a écrit :
> Le lun 06/01/2003 à 07:24, Ananth Kesari a écrit :
> > What we are looking for is to find out whether or not the current
> > autotool input files of PHP support the ability to produce a spearate
> > phplib.l and the appropriate "main" module - one for Apache 1.3, one for
> > Apache 2.0, one for command line etc. each of which can use the same
> > phplib.l ?
> > 
> > We tried to figure this out on Linux, but it appears that this seems
> > not to be supported. Are we correct in our findings? Or is there really
> > a way of doing the above of having different shared modules?
> 
> It is not supported officially, but there's a way to do it.
> 
> As I promised a couple of days ago, here is a solution that works for
> me, though it's not very pretty. I could of course modify the m4 files,
> but it's left as an exercise to the readers of this list ;-) 
> 
> Here is the procedure:
> 1) Patch the makefile.global and configure script using the
> "shared-patch" I enclosed in this mail. This will compile a shared
> library containing the PHP core, and will patch the CGI and CLI version
> so they use this library.
> 
> 2) do ./configure, with all the options that you want, but do *not* use
> the --with-apache or --with-apxs options. You want to compile first the
> CGI and CLI binaries and the shared library.
> 
> 3) do a make, but do not do a make install yet.
> 
> 4) To compile the Apache 1.3 module, use the enclosed "do1.3" script.
>If your Apache environment is setup correctly, you will have a
>libphp4.so in the sapi/apache directory. This is the Apache DSO that
>you'll need to copy in your Apache 1.3 modules directory.
> 
> 5) To compile the Apache 2.0 module, use the enclosed "do2.0" script.
>If your Apache environment is setup correctly, you will have a 
>mod_php4.so in the sapi/apache2filter/.libs directory. This is the
>Apache 2.0 DSO that you'll need to copy in your Apache 2.0 modules
>directory.
> 
>Please note that to be able to compile both Apache 1.3 and Apache 2.0
>modules, you need two different apxs binaries and two different
>apache include directories. I personnaly use the following dirs:
>Apache 1.3: /usr/sbin/apxs and /usr/include/apache for 1.3 
>Apache 2.0: /usr/sbin/apxs2 and /usr/include/apache2
> 
> 6) Finally, place the libphp_common library in /usr/lib
>mv libphp_common.so libphp_common.so.430
>ln -s libphp_common.so.430 libphp_common
>cp libphp_common* /usr/lib
> 
> 7) Now do a "make install", "make install-cli"
> 
> 8) Finally, you can install sapi/cgi/php to whatever location/name you
>want that is different from the CLI version.
> 
> 9) You'll still need to tweak your httpd.conf to put the required
>LoadModule, AddModule and AddType directives.
> 
> 10) Or better yet, install Mandrake Linux and have it already
> pre-configured ;-)
> 
> 
> Regards,
> 
> Jean-Michel Dault
> Apache/PHP Packager
> Mandrake Linux
> 


diff -urp php-4.3.0.orig/configure php-4.3.0/configure
--- php-4.3.0.orig/configure	2002-12-27 00:50:56.0 -0400
+++ php-4.3.0/configure	2003-01-04 05:52:46.0 -0400
@@ -5681,10 +5681,10 @@ if test "$PHP_SAPI_CLI" != "no"; then
 BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
 ;;
   *)
-BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
+BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) -L. -lphp_common \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
 ;;
   esac
-  INSTALL_CLI="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(bindir); \$(INSTALL) -m 0755 \$(SAPI_CLI_PATH) \$(INSTALL_ROOT)\$(bindir)/php"
+  INSTALL_CLI="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(bindir); \$(INSTALL) -m 0755 \$(SAPI_CLI_PATH) \$(INSTALL_ROOT)\$(bindir)/php-cli"
   
   PHP_VAR_SUBST="$PHP_VAR_SUBST BUILD_CLI"
 
@@ -8448,7 +8448,7 @@ EOF
 BUILD_CGI="\$(CC) \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(NATIVE_RPATHS) \$(PHP_GLOBAL_OBJS:.lo=.o) \$(PHP_SAPI_OBJS:.lo=.o) \$(PHP_FRAMEWORKS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CGI_PATH)"
   ;;
   *)
-BUILD_CGI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_SAPI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CGI_PATH)"
+BUILD_CGI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LD

Re: [PHP-DEV] PHP building on Linux: A question on configure script!

[Jean-Michel Dault]

Le lun 06/01/2003 à 07:24, Ananth Kesari a écrit :
> What we are looking for is to find out whether or not the current
> autotool input files of PHP support the ability to produce a spearate
> phplib.l and the appropriate "main" module - one for Apache 1.3, one for
> Apache 2.0, one for command line etc. each of which can use the same
> phplib.l ?
> 
> We tried to figure this out on Linux, but it appears that this seems
> not to be supported. Are we correct in our findings? Or is there really
> a way of doing the above of having different shared modules?

It is not supported officially, but there's a way to do it.

As I promised a couple of days ago, here is a solution that works for
me, though it's not very pretty. I could of course modify the m4 files,
but it's left as an exercise to the readers of this list ;-) 

Here is the procedure:
1) Patch the makefile.global and configure script using the
"shared-patch" I enclosed in this mail. This will compile a shared
library containing the PHP core, and will patch the CGI and CLI version
so they use this library.

2) do ./configure, with all the options that you want, but do *not* use
the --with-apache or --with-apxs options. You want to compile first the
CGI and CLI binaries and the shared library.

3) do a make, but do not do a make install yet.

4) To compile the Apache 1.3 module, use the enclosed "do1.3" script.
   If your Apache environment is setup correctly, you will have a
   libphp4.so in the sapi/apache directory. This is the Apache DSO that
   you'll need to copy in your Apache 1.3 modules directory.

5) To compile the Apache 2.0 module, use the enclosed "do2.0" script.
   If your Apache environment is setup correctly, you will have a 
   mod_php4.so in the sapi/apache2filter/.libs directory. This is the
   Apache 2.0 DSO that you'll need to copy in your Apache 2.0 modules
   directory.

   Please note that to be able to compile both Apache 1.3 and Apache 2.0
   modules, you need two different apxs binaries and two different
   apache include directories. I personnaly use the following dirs:
   Apache 1.3: /usr/sbin/apxs and /usr/include/apache for 1.3 
   Apache 2.0: /usr/sbin/apxs2 and /usr/include/apache2

6) Finally, place the libphp_common library in /usr/lib
   mv libphp_common.so libphp_common.so.430
   ln -s libphp_common.so.430 libphp_common
   cp libphp_common* /usr/lib

7) Now do a "make install", "make install-cli"

8) Finally, you can install sapi/cgi/php to whatever location/name you
   want that is different from the CLI version.

9) You'll still need to tweak your httpd.conf to put the required
   LoadModule, AddModule and AddType directives.

10) Or better yet, install Mandrake Linux and have it already
pre-configured ;-)


Regards,

Jean-Michel Dault
Apache/PHP Packager
Mandrake Linux


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

RE: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?

[Rasmus Lerdorf]

It's gif read-only, so you only have imagecreatefromgif()

On Mon, 6 Jan 2003, Brian Weil wrote:

> Thanks a million,
>
> Can you tell me which gif functions are available in this build?
>
> Thanks Again,
> Brian
>
> -Original Message-
> From: Edin Kadribasic [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 05, 2003 5:59 PM
> To: Brian Weil; Rasmus Lerdorf
> Cc: PHP developer list
> Subject: Re: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?
>
>
> Hello,
>
> Read-only GIF support has now been enabled in the windows version of the
> bundled GDLIB. Fixed version of php_gd2.dll compatible with PHP 4.3.0
> will be available from
> http://snaps.php.net/win32/php4-win32-STABLE-latest.zip in approx. 8
> hours.
>
> Edin
>
> - Original Message -
> From: "Brian Weil" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Sunday, January 05, 2003 6:31 PM
> Subject: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?
>
>
> > So...
> >
> > WIll gif support ever be available on win32? Can a patched gd.dll be
> > found somewhere with readonly gif support or will we have to
> > re-install php when the binary is updated? I've been (patiently)
> > waiting for this since GD1.6.
> >
> > Thanks,
> > Brian
> >
> > "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message
> > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > Hrm..  Whoever built the Windows binary didn't define
> > > HAVE_GD_GIF_READ I guess.  Or perhaps it should go into
> > > main/config.w32.h.in assuming we
> are
> > > always going to build the windows binary against the bundled gd
> > > library.
> > >
> > > -Rasmus
> > >
> > > On Fri, 3 Jan 2003, Zac Barton wrote:
> > >
> > > > hi all, i thought php 4.3 was ment to have read-only access to gif
> > images?
> > > >
> > > >
> > > > all i get via phpinfo(); is:
> > > >
> > > > GD Support  enabled
> > > > GD Version  bundled (2.0 compatible)
> > > > FreeType Support  enabled
> > > > FreeType Linkage  with freetype
> > > > JPG Support  enabled
> > > > PNG Support  enabled
> > > > WBMP Support  enabled
> > > >
> > > > wheres the gif read support?
> > > >
> > > > php 4.3 d/loaded via www.php.net so its the correct version.. what
>
> > > > am
> i
> > > > missing?
> > > >
> > > > does gif read support mean i can load a gif image then output it
> > > > as a
> > PNG?
> > > >
> > > > many thanks in advance
> > > >
> > > > zac barton
> > > >
> > > > --
> > > > PHP Windows Mailing List (http://www.php.net/)
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

RE: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?

[Brian Weil]

Thanks a million,

Can you tell me which gif functions are available in this build?

Thanks Again,
Brian

-Original Message-
From: Edin Kadribasic [mailto:[EMAIL PROTECTED]] 
Sent: Sunday, January 05, 2003 5:59 PM
To: Brian Weil; Rasmus Lerdorf
Cc: PHP developer list
Subject: Re: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?


Hello,

Read-only GIF support has now been enabled in the windows version of the
bundled GDLIB. Fixed version of php_gd2.dll compatible with PHP 4.3.0
will be available from
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip in approx. 8
hours.

Edin

- Original Message -
From: "Brian Weil" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, January 05, 2003 6:31 PM
Subject: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?


> So...
>
> WIll gif support ever be available on win32? Can a patched gd.dll be 
> found somewhere with readonly gif support or will we have to 
> re-install php when the binary is updated? I've been (patiently) 
> waiting for this since GD1.6.
>
> Thanks,
> Brian
>
> "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message 
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Hrm..  Whoever built the Windows binary didn't define 
> > HAVE_GD_GIF_READ I guess.  Or perhaps it should go into 
> > main/config.w32.h.in assuming we
are
> > always going to build the windows binary against the bundled gd 
> > library.
> >
> > -Rasmus
> >
> > On Fri, 3 Jan 2003, Zac Barton wrote:
> >
> > > hi all, i thought php 4.3 was ment to have read-only access to gif
> images?
> > >
> > >
> > > all i get via phpinfo(); is:
> > >
> > > GD Support  enabled
> > > GD Version  bundled (2.0 compatible)
> > > FreeType Support  enabled
> > > FreeType Linkage  with freetype
> > > JPG Support  enabled
> > > PNG Support  enabled
> > > WBMP Support  enabled
> > >
> > > wheres the gif read support?
> > >
> > > php 4.3 d/loaded via www.php.net so its the correct version.. what

> > > am
i
> > > missing?
> > >
> > > does gif read support mean i can load a gif image then output it 
> > > as a
> PNG?
> > >
> > > many thanks in advance
> > >
> > > zac barton
> > >
> > > --
> > > PHP Windows Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>



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

Re: [PHP-DEV] Generic expressions interpolation in strings

[Andrey Hristov]

- Original Message -
From: "Leon Atkinson" <[EMAIL PROTECTED]>
To: "Federico Giannici" <[EMAIL PROTECTED]>; "John Coggeshall"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 7:09 PM
Subject: Re: [PHP-DEV] Generic expressions interpolation in strings


> > print << > 
> > Name:{$= text2html($data['name']) }
> > Address:
> > 
> > END;
>
> Federico, you can always do this:
>

 And that's is the better and preffered way

> ?>
> 
> Name:
> Address:
> 
> 
> Cheers,
> Leon
>
Andrey


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

Re: [PHP-DEV] Generic expressions interpolation in strings

[Leon Atkinson]

> print << 
> Name:{$= text2html($data['name']) }
> Address:
> 
> END;

Federico, you can always do this:

?>

Name:
Address:

http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Generic expressions interpolation in strings

[Federico Giannici]

I really cannot understand where is the danger of "executing a system call"!
What is the difference between these two cases:

1) Evaluate an expression, assign it to a temporary variable and then print
   it into an heredoc string.

2) Evaluate the expression directly INSIDE the heredoc string.


Let me explain it again.

Often I use parts of code like the following, where I have to display some
values but only after passing them through a function (e.g. to escape them).

Currently I have to use temporary variables to keep the escaped values:

$name = text2html($data['name']);
$address = htmlspecialchars($data['address']);
print <<
Name:$name
Address:

END;


Indeed, I'd like to escape the values DIRECTLY inside the heredoc string:

print <<
Name:{$= text2html($data['name']) }
Address:

END;


I find the latter much more handy, readable, and don't force me to
fill the namespace with useless variables!

I don't think it should be difficult to implement this syntax.
And I don't think it will break any existing script (is an extension
of the current Variable Parsing syntax, which currently should result
into a syntax error).

Bye.


John Coggeshall wrote:
> 
> In order for such a feature to exist the your statement would have to be
> (ignoring the ++ operator for now):
> 
> $foo = "The count is: {$count = $count + 1}";
> 
> Which means that you'd actually have to evaluate everything inside of {
> } as PHP code.. Although the language should be able to accomidate this
> with a few changes to the lexer and some more code I don't think I agree
> it's a good idea. Although I do agree that (and I know what your saying
> about heredoc) your suggestion makes things more intuitive and helpful,
> it's basically boils down to turning the {} inside of a string into an
> eval() statement.. And that I don't agree with:
> 
>  
> // assume $count['a'] has the following value from a form or
> something...
> 
> $count = "system('rm -Rf *');";
> 
> $foo <<< EOF
> The value of count is: {$count['a']}
> EOF;
> 
> Which would end up executing a system call... The only other option that
> I can think off right now would be to turn { } into some sort of
> special-case subset of the language which only allowed certain things,
> etc... And that is really much more of a headache that it's worth.
> 
> John
> 
> 
> >-Original Message-
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >Sent: Sunday, January 05, 2003 1:45 PM
> >To: [EMAIL PROTECTED]
> >Subject: [PHP-DEV] Generic expressions interpolation in strings
> >
> >
> >I already opened a bug (#21433) about this Feature Request,
> >but I realized it is better to discuss here about it.
> >
> >
> >I'm relatively new to PHP. Previously I used to program a lot
> >in Perl. What I really lack in PHP is Perl's ability to
> >interpolate any expression inside a string. For example:
> >
> >Perl: "Next value is @{[ $value + 1 ]}!"
> >PHP:  "Next value is " . $value + 1 . "!"
> >
> >In this simple case it's not a great problem, but it becomes
> >more awkward when using the heredoc operator. In this cases
> >I'm often forced to use temporary variables:
> >
> >$tempvar = $value + 1;
> >print <<< END
> >Here it is the next value
> >$tempvar
> >Other text...
> >END;
> >
> >
> >I propose to extend the Variable Parsing syntax to evaluate
> >ANY expression instead of variables only. I propose the
> >following syntax:
> >
> >print <<< END
> >Here it is the next value
> >{$= $value + 1 }
> >Other text...
> >END;
> >
> >Using "{=" would be more readable but it would cause too many
> >backward compatibility problems...
> >
> >
> >What do you think of this?
> >
> >
> >Thanks.

-- 
___
__
   |-  [EMAIL PROTECTED]
   |ederico Giannici  http://www.neomedia.it
___

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

Re: [PHP-DEV] What headers/libs does Win32 Snaps build use?

[Michael Sisolak]

> > As I was looking into my build of Win32 failing becuase it tried to
> > link to a non-existant zlib.lib (the win32build.zip version is
called
> > zlibstat.lib), it occured to me that everything does build fine on
the
> > snapshot machine.
> 
>  Check out the zlib CVS module and place it in the same directory the
>  php4 module was checked out to. Build both Debug and Release
versions
>  of zlib and you should be set up.

Yeah, Zeev pointed that out to me.  My question is really about all the
other libraries that are needed to get the Windows version to compile. 
Things like the OpenSSL and GD image libaries.  I like to recompile the
PHP I run to be release_inline and to turn off some of the standard
libraries that I never use.  If we provided the library/header set that
the snaps machine uses to build PHP with, then I could make a build
that exactly matches the official Win32 build except for what I wanted
to be different.

Basically what I'm talking about is updating win32build.zip so that it
has all the current libraries that are really used to do a PHP build on
Win32.  Is there a practical or licensing reason why that couldn't be
done?  Would it be a lot more work than just packaging up a few
directories on the snaps machine?

Michael Sisolak
[EMAIL PROTECTED]


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

RE: [PHP-DEV] Generic expressions interpolation in strings

[John Coggeshall]

In order for such a feature to exist the your statement would have to be
(ignoring the ++ operator for now):

$foo = "The count is: {$count = $count + 1}";

Which means that you'd actually have to evaluate everything inside of {
} as PHP code.. Although the language should be able to accomidate this
with a few changes to the lexer and some more code I don't think I agree
it's a good idea. Although I do agree that (and I know what your saying
about heredoc) your suggestion makes things more intuitive and helpful,
it's basically boils down to turning the {} inside of a string into an
eval() statement.. And that I don't agree with:


EOF;

Which would end up executing a system call... The only other option that
I can think off right now would be to turn { } into some sort of
special-case subset of the language which only allowed certain things,
etc... And that is really much more of a headache that it's worth.

John
 

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
>Sent: Sunday, January 05, 2003 1:45 PM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] Generic expressions interpolation in strings
>
>
>I already opened a bug (#21433) about this Feature Request, 
>but I realized it is better to discuss here about it.
>
>
>I'm relatively new to PHP. Previously I used to program a lot 
>in Perl. What I really lack in PHP is Perl's ability to 
>interpolate any expression inside a string. For example:
>
>Perl: "Next value is @{[ $value + 1 ]}!"
>PHP:  "Next value is " . $value + 1 . "!"
>
>In this simple case it's not a great problem, but it becomes 
>more awkward when using the heredoc operator. In this cases 
>I'm often forced to use temporary variables:
>
>$tempvar = $value + 1;
>print <<< END
>Here it is the next value
>$tempvar
>Other text...
>END;
>
>
>I propose to extend the Variable Parsing syntax to evaluate 
>ANY expression instead of variables only. I propose the 
>following syntax:
>
>print <<< END
>Here it is the next value
>{$= $value + 1 }
>Other text...
>END;
>
>Using "{=" would be more readable but it would cause too many 
>backward compatibility problems...
>
>
>What do you think of this?
>
>
>Thanks.
>-- 
>___
>__
>   |-  [EMAIL PROTECTED]
>   |ederico Giannici  http://www.neomedia.it
>___
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

Re: [PHP-DEV] CLI behavior with -q switch

[Roberto Biancardi]

Roberto Biancardi ha scritto:


another compatibility issue beetween cgi and cli is the fact that the 
cli version
does not send error messages to stderr as the cgi version did.  is 
this the
intended behaviour ?

not true. i had some mess with .ini files.

sorry.

--
--  Roberto Biancardi  --  +39 02 22475231  --  [EMAIL PROTECTED]  --



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

[PHP-DEV] OSX Project Builder and PHP Developement

[Christian Stocker]

Hi

Is anyone using Apple's Project Builder for developing PHP? Or did someone
try and gave up, because it's not usable? It looks like a nice IDE, but
targeted at Java and Obj-C..

If anonye uses it, could you publish the .pbproj file, so I don't have to
fiddle around with all those settings ;)

On the other hand, compiling PHP on OSX from the command line works
excellent and I will stick to that, if PB isn't that great.

chregu





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

Re: [PHP-DEV] Using PHP for search and replace

[Jean-Michel Dault]

Le lun 06/01/2003 à 06:35, Paul Gregg a écrit :
> > perl -pi -e "s|^;extension=mysql.so|extension=mysql.so|" /etc/php.ini
> > Is there a quick and easy way to do this kind of thing in PHP? Or would
> I was about to say "Ask the RPM makers" until I saw who was asking :-)

Everyone's doing that.. RedHat, SuSe, PLD, Mandrake... so obviously no
RPM guy has ever tried something else ;-)

> How about:
> php -q -r '$lines=file("/etc/php.ini"); $f=fopen("/etc/php.ini", "w"); \
> foreach ($lines as $line) { fwrite($f, preg_replace("/^;extension=mysql.so/",\
> "extension=mysql.so", $line)); } fclose($f);'

I'll try that, thanks!

> I presume perl is no longer a "standard" package installed with either
> redhat or mandrake thus the question ?

No, it's just that it's pretty weird to have a Prereq: perl in a PHP
package. Imagine the irony, you install the best scripting language
(PHP) and you need its competitor (Perl) to be able to use install it
;-)

Jean-Michel


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

Re: [PHP-DEV] CLI behavior with -q switch

[Roberto Biancardi]

Jean-Michel Dault ha scritto:


The problem is that the -q switch is still in the CLI for backward
compatibility, but it breaks scripts because it does not change
directories.

I would strongly suggest that the -q switch would imply changing the
working directory to that of the script, unless overriden by -C.

 

i'am in the same condition of Jean-Michel (maintaning some php scripts) 
and i think
this is a very good thing to do.

another compatibility issue beetween cgi and cli is the fact that the 
cli version
does not send error messages to stderr as the cgi version did.  is this the
intended behaviour ?

thanks,

--
--  Roberto Biancardi  --  +39 02 22475231  --  [EMAIL PROTECTED]  --



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

Re: [PHP-DEV] PHP building on Linux: A question on configurescript!

[Ananth Kesari]

Hi,

Please refer to the mail given below that I sent you earlier. You had
told us that --with-apxs is the way to go. But we still have the same
issue.

Let me explain:

We currently use "apxs" to build a PHP "DSO" for Apache 1.3. We haven't
gotten around to trying it for Apache 2.0 yet. The problem we have is
that the core PHP piece, which used to be in a separate loadable module
called phplib.l, is not produced anymore. But this is part of one single
PHP Apache module php_apache.sim, which is specific to Apache 1.3. As
you can see, if we want to build PHP for Apache 2.0, then we would have
to produce another "DSO" for Apache 2.0 (php_apache2.sim or something
like that) which will *also* have embedded in the core PHP part that was
in phplib.l (.l indicates a shared library, .SIM is also a shared
library, but a special one.)

What we are looking for is to find out whether or not the current
autotool input files of PHP support the ability to produce a spearate
phplib.l and the appropriate "main" module - one for Apache 1.3, one for
Apache 2.0, one for command line etc. each of which can use the same
phplib.l ?

We tried to figure this out on Linux, but it appears that this seems
not to be supported. Are we correct in our findings? Or is there really
a way of doing the above of having different shared modules?

Your clarifications on this is highly appreciated.

Thanks,
Ananth.

>>> "Ananth Kesari" <[EMAIL PROTECTED]> 12/13/02 08:00PM >>>
Hi,

I am involved in porting PHP for NetWare.

We are now looking at and trying to understand how PHP is built on
Linux. I have a question for the same. It could be a newbie question on
configure script since we are new to Linux. Please help.

The question is like this:

On NetWare:
We generate mod_php executable as the Apache module which Apache loads
when appropriately configured. This in turn will use the phplib
executable which has the TSRM, ZEND, all the standard extensions and
libraries built into it. Then we have separate executables for
extensions like MySQL, LDAP, XML etc.

On Linux:
We are trying to look at building a similar binaries on Linux also. Is
that how it is done on Linux also?

To build for Apache on Unix, it appears that we have to use the
following options in the configure script to get the equivalent of what
I mentioned above:

--with-apache= --disable-posix 
--with-mysql=shared --with-ldap=shared --enable-ftp --enable-bcmath 
--enable-calendar

The problem in this approach is that we seem to be getting a static
library (xxx.a) as an output. We are not clear what we are supposed to
do with this library! Perhaps this needs to be then built along with
Apache into the Apache executable.

There is an option called:

--with-apxs=

which seems to produce a "DSO" which doesn't seem to work on Linux. The
build fails due to errors in the apxs script.

So, isn't it possible to produce on Linux, the equivalent of what I
mentioned above for NetWare? If so, what options do we need to use for
the configure process? We need to understand whether we are not using
the right options or whether it is simply not possible to do so with
what we have. The latter meaning that we need to make the necessary
modifications to the input files to get what we want.

Your early reply on this is highly appreciated.

Thanks,
Ananth.


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

Re: [PHP-DEV] CGI and CLI [packaging issues]

[Marcus Börger]

At 06:55 06.01.2003, Jean-Michel Dault wrote:

Le sam 04/01/2003 à 18:13, Marcus Börger a écrit :
> What might happen is that CLI becomes widely accepted and scripts
> calling php from shebang lines. Id so your above solution is a bad idea
> and i hope CLI will be...

I'm CC'ing the maintainers of PHP for most distributions of Linux, so we
can all be in sync. For those that don't know the issue, I'll resume it
by saying that with PHP 4.3, there is a new CLI (command-line interface)
that complements the CGI interface. The problem is, both files are named
"php".


This will help a lot when coming from you.


Here is the solution that I have been experimenting over the past few
days, and that will be implemented in Mandrake Cooker (and soon 9.1):

- There will be two RPMS: php-cli and php-cgi.
- Both packages will provide php
- Using the "update-alternatives", each package will contain
 /usr/bin/php as a symlink to the respective binary. This lets us give a
priority to which binary is called for a given symlink. php-cli will be
given priority 20 (higher), php-cgi will be given priority 10 (lower)
- If only one package is installed, /usr/bin/php will link to the right
executable.
- By default, php-cgi will be installed, in order to maintain backwards
compatibility.
- Users will be able to install the CLI using rpm -i php-cli
- If both packages are installed, php-cli will be called since it's
higher priority.
- All packages that specifically require the command-line interface
(there is none for the moment, but there will be in the future), will
explicitely require php-cli.

This setup means that we don't break the configuration of people that
already have the php CGI interface, while, with one simple command, the
new PHP command-line enthusiasts will be able to have their cake.

This goes with the PHP source approach:
By default, "configure/make/make install" compiles the CGI interface,
and then you have to "make install-cli" to get the CLI.

We just replace the "make install-cli" by "urpmi/apt-get php-cli".

Comments/Questions/Suggestions welcome.

Jean-Michel Dault
PHP/Apache packager
Mandrake Linux


From my point of view this is the best solution :-))

regards
marcus aka helly


--
--
Marcus Börger - Looking for all sorts of freelance work - just ask...

Did i help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0
--

Re: [PHP-DEV] Using PHP for search and replace

[Paul Gregg]

In mail.php.internals, Jean-Michel Dault <[EMAIL PROTECTED]> wrote:
> Hello all,
> 
> Currently, both Mandrake and RedHat use the following trick:
> perl -pi -e "s|^;extension=mysql.so|extension=mysql.so|" /etc/php.ini
> 
> This sucks, because you then need perl to install a PHP extension.
> We sure could use sed, but this requires a temporary file, and this
> creates some security risks.
> 
> Is there a quick and easy way to do this kind of thing in PHP? Or would
> this be something that we could integrate?

I was about to say "Ask the RPM makers" until I saw who was asking :-)

How about:

php -q -r '$lines=file("/etc/php.ini"); $f=fopen("/etc/php.ini", "w"); \
foreach ($lines as $line) { fwrite($f, preg_replace("/^;extension=mysql.so/",\
"extension=mysql.so", $line)); } fclose($f);'

or php-cli -r '..' (as above)

?

It'd probably be better to read from the php.ini-dist file or the source in
the package and write to php.ini, but the above will work* if it isn't 
interrupted (which would probably cause other issues with the rpm, so isn't
a biggie).
* I typed this out without testing it, so it might not work :)

I presume perl is no longer a "standard" package installed with either
redhat or mandrake thus the question ?

Paul.

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

Re: [PHP-DEV] CVS Account Request: buddhike

[Andrey Hristov]

 For adding comments in the manual on the web CVS account is not needed.

Andrey

- Original Message -
From: "Buddhike de Silva" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 12:37 PM
Subject: [PHP-DEV] CVS Account Request: buddhike


> I would like to give my comments like other's have done in PHP manual.
I've been using PHP since 2001 and pretty confident with it. Please let me
add my comments on the Help Pages
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

[PHP-DEV] "add_property_*", "set_constructor" and more ...

[Stefano Corsi]

Hello.

I have managed porting my Zend1 objects to the new object structure and I have 
some ideas or doubts I want to share:

Properties
---

The "add_property_*" function pool updates zval->value->obj->properties 
(Z_OBJPROP_P), while now the correct HastTable to update is in 
Z_OBJ_P(zval)->properties.
So I created a new set of functions (temporarily) named "add_objprop_*" that 
updates the right HashTable, and I created a macro 

#define add_property add_objprop

in case ZEND_ENGINE_2 should be defined inside my files.

It seems to work fine.

What will be the policy for properties in the future? Will be a separate set 
of functions for the new object or will the "add_property_*" set be modified?

Constructor
-

Furthermore, my object had no costructor with the new model and there seems 
not to be an API function to assign constructors. I used this little 
function:

ZEND_API int set_constructor(zend_class_entry ** class_entry, char * 
constructor_name) {
/*
 *  I use a zend_op_array because
 *  I cannot figure out how to populate a (zend_function *)
 *  otherwise ...
 */
zend_op_array * func_method;

if (zend_hash_find(
&(*class_entry)->function_table,
constructor_name,
strlen(constructor_name) + 1,
(void **) &func_method) == FAILURE) {
return FAILURE;
}

(*class_entry)->constructor = (zend_function *) func_method;
return SUCCESS;
}

and this function should be called from the MINIT function this way:

// an_object
INIT_OVERLOADED_CLASS_ENTRY
(ce,
 "an_object",
 php_an_object_class_functions,
 NULL, NULL, NULL);
an_object_class_entry = zend_register_internal_class_ex(&ce, NULL, NULL 
TSRMLS_CC);
#ifdef ZEND_ENGINE_2
set_constructor(&an_object_class_entry, "scobject");
#endif

Constructor return value
---

I used before a this syntax to return value from constructors.

SEPARATE_ZVAL(&zval); \
*return_value = *zval; \
FREE_ZVAL(zval);

now I have noticed I should use this:

*return_value = *zval;
zval_copy_ctor(return_value);

I have some more function for dealing with objects. If someone is interested I 
cand send it outside the list.

Regards,
Stefano

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

[PHP-DEV] CVS Account Request: buddhike

[Buddhike de Silva]

I would like to give my comments like other's have done in PHP manual. I've been using 
PHP since 2001 and pretty confident with it. Please let me add my comments on the Help 
Pages

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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mysql php_mysql.c

[Sebastian Bergmann]

Georg Richter wrote:
> georg Sun Jan  5 15:53:06 2003 EDT
>
>   Modified files:
> /php4/ext/mysql   php_mysql.c
>   Log:
>   fixed bug #21435

   php_mysql.c(1004): warning C4047: 'function':
   Anzahl der Dereferenzierungen bei 'struct _zval_struct ** ' und
   'struct _zval_struct *' unterschiedlich

   php_mysql.c(1004): warning C4024: 'zend_fetch_resource':
   Unterschiedliche Typen fuer formalen und uebergebenen Parameter 1

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/gd gd_bundled.dsp

[Sebastian Bergmann]

Edin Kadribasic wrote:
> edink Sun Jan  5 20:39:08 2003 EDT
>
>   Modified files:
> /php4/ext/gd  gd_bundled.dsp
>   Log:
>   Complete gif readonly support addition by adding missing gd_gif_in.c
>   file to the project.

  Thank you, Edin. I overlooked gd_gif_in.c somehow :-/

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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