This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Pre-ITP: apache/mod_php


Gerrit P. Haase schrieb:
but it can easily be patched on our side.

Yes? How? I removed ldap from the build list.

By the gbs, which patches/fixes the Makefile after the configure run :)
a sed or perl line maybe.

The Makefile is dynamically created by configure as is Makefile.objects?

sure.


I'm just too lazy to understand ext/ldap/config.m4
If someone is able to fix that, it should be fixed upstream.
Wonder why it doesn't fail on linux then...

There are no such problems like undefined references, if the relevant SO is not in PATH it will fail during runtime and not during linktime.

all our cyg*.dll (required by the extensions) are in the path,
and the php extensions are looked up in the special extension_dir path (specified in php.ini).
their absolute path is given to dlopen(), which should work.


What is the general rule of thumb with the shared lib and CLI & CGI
executables?  Put all global objects in the library, put the sapi
objects into the CGI exe and the CLI objects in the CLI exe?

before some time the cli and cgi exe have been the same. they just seperated it lately, so that the cli is smaller and faster. no special
server env's, fastcgi support. cgi has the -b switch, and cli got the
PHP_MODE_CLI_DIRECT mode.

all exe and sapi modules should just the use main shared /usr/bin/cygphp4.dll (or php4ts.dll as it is called on the windows side)

What are the main objects for the CGI exe and for the CLI exe?

you mean the .o files? or the features? see sapi/cgi, sapi/cli esp. sapi/cli/README:

"The CLI (command line interface) SAPI has been introduced
with a goal of making PHP better at supporting the creation of
stand alone applications.

It is based on CGI SAPI with all CGI specific things removed.

The main differences between the two:

* CLI is started up in quiet mode by default.
  (-q switch kept for compatibility)
* It does not change the working directory to that of the script.
  (-C switch kept for compatibility)
* Plain text error message
* $argc and $argv registered irrespective of register_globals
  and register_argc_argv php.ini settings.
* implicit_flush always on
* -r option which allows execution of PHP code directly from
  the command line (e.g. php -r 'echo md5("test");' )
* max_execution_time is set to unlimited, overriding php.ini setting."

The gtk-enabled php cli is also based on that, just with an invisible console.

otherwise just phpize your extension again. that's quite easy and works
fine.
> Interesting, what is phpize?

The configure helper to create an extension. see scripts/phpize.
It is then ready for make and make install

BTW, brian: /usr/lib/php4 is really not a very good idea, unless you fix phpize and the other scripts also.
all of them expect ${prefix}/lib/php/... even in the .in files.
please stay with the standards.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]