This is the mail archive of the 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

Brian Dessent schrieb:
Reini Urban wrote:
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.

Okay, that's good to know. I can go back to using /usr/lib/php for php4, but what's the "standard" for php5? /usr/lib/php5? Surely they don't expect you to run one or the other but not both?

that's a problem I avoided so far. officially they cannot coexist under /usr/lib/php, but the extension_dir is seperated and the dll naming is versioned.

How about configs?  I tend to prefer having a directory, /etc/php or
/etc/php4, under which you have your php.ini-recommended and/or
php.ini-dist, with a postinstall that copies to php.ini if none already
exists.  I'd rather not pollute /etc with all that, and worry about php4
and php5 ini names colliding.  Is there any problem that you see with
doing it like this?

officially the .ini is at /usr/lib/php/ if we make /usr/lib/php5/ that's okay then. I never saw it in /etc but I don't know that many distros. I always compiled my own php into /usr/local/.

it's true that coexistance is crucial.

Also, I have clearly not put a lot of thought into the CLI/CGI versions
and PEAR. However it looks like there could be a lot of path decisions
there, so I suppose I shouldn't try to put it off for a later release. I'm fine with offering CLI and PEAR, but I have no intention to also
support a CGI package at the moment. The typical reason for wanting PHP
as a CGI instead of a module is so that you can use suexec or other
similar security tools to cope with multiple user accounts all being
able to upload .php files. However, I would not want to trust Cygwin
for this regardless, so I just don't see it as being a common need. I
see it more as filling the "developer testbed" niche, so that you can
develop your apps locally and then copy them over to your real server
when done. I'm sure people will want to use Cygwin/Apache/PHP in
production, but I'm hoping that it remains a small number of these

another purpose:
the php5 cgi is so far the best solution to debug php5. (besides with non-free debuggers like kommodo and xdebug).
php5 debugging as module has poor support by Zend, it is closed source, and the cgi version doesn't need a binary compatible debugging dll. that's why I need the cgi for php5 at least.
besides, supporting the CGI target is not really an issue. just one additional exe to put somewhere:
/usr/lib/bin/php.exe or /var/www/cgi-bin/php.exe

Another issue: currently in my setup cygphp4.dll is being put in
/usr/lib/apache/, with all the other Apache DSOs.  This is not in the
path by default.  I was under the impression that this does not matter,
since cygphp4.dll is already loaded by the time that the extensions are
activated, so the fact that they're linked against it but it's not in
the path shouldn't matter.  However, if that's not the case and it does
need to live in /usr/bin then that will complicate the Apache setup
slightly.   I tend to think it would be better to simply require this
path added to $PATH of the service if it becomes an issue, rather than
have Apache modules strewn about more than one place.

you confused me :)
let me explain. cygphp4.dll is the shared master php library (there's no /usr/lib/libphp4.a), and there exist various sapi interfaces to communicate between the server and the cygphp4.dll.
stipe had just one big /usr/lib/apache/libphp4.dll, which was the apache module and the php lib together. the cgi and cli couldn't use it.

the call path is like this:
/usr/sbin/httpd.exe => /usr/lib/apache/mod_php4.dll
/usr/lib/apache/mod_php4.dll => /usr/bin/cygphp4.dll
/usr/bin/cygphp4.dll => <extension_dir>/php_<ext>.dll

/usr/bin/php.exe             => /usr/bin/cygphp4.dll
/usr/lib/php/bin/php.exe     => /usr/bin/cygphp4.dll

couldn't you make your gbs and patch avialable somewhere, so that we (gerrit and me), can try it out? and try to add as much extensions as possible.

BTW: 4.3.9 and 5.0.2 are officially released now.
At least 4.3.9 is a major improvement, since I (phpwiki) was hit by the PCRE memory exhaustion bug. There's also GIF support.
Reini Urban

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