Pre-ITP: apache/mod_php

Reini Urban rurban@x-ray.at
Thu Sep 23 17:50:00 GMT 2004


Brian Dessent schrieb:
> I think I have finally worked out the kinks in the crappy PHP build
> system.  I managed to banish that awful "mkdll.sh" business.  The
> results after "make" are simply cygphp4.dll and the php4_*.dll ready to
> be used.  Oh, and none of that rebasing hassle seems to be required. 
> Cheers to whatever binutils/gcc changes that made that one possible.

!!! see see !!! thanks a lot.

> I can now cleanly build PHP 4.3.8 as an Apache DSO with the following
> modules/extensions:
> 
> A) Internal / Built-In:
> ctype, mime_magic, overload, posix, session, sockets, standard,
> tokenizer

just please add --with-memory-limit because this causes a lot of 
problems on the poor sf.net server (php-4.1.2 with memory-limit=8MB), 
and it is best to verify your app at home with the settings under the 
worst circumstances. which is sf.net.

> B) Compiled in cygphp4.dll (bundled libs) / won't work shared:
> bcmath, calendar, dba (gdbm, cdb, cdb_make, inifile, flatfile), dbase,
> dbx, dio, exif, filepro, ftp, mysql, pcre, xml

good to have these static.

> Note however: xml uses to system expat and gdbm uses to system gdbm. 
> The other dbm's could also be added (Berkeley db 4.x, 3.x, 2.x) but they
> didn't work right out of the box and would require more m4 patches so I
> didn't bother.  I left the pcre as the PHP bundled lib as the config
> option for it is very scary and says you should only switch to system
> pcre if you really know what you're doing.  :-)

yes, berkeley is a beast. db4 would be fine. but if gdbm is supported, 
this would cover most of the cases.

> C) Fully shared (activated in php.ini and dlopen'd from a DLL):
> bz2, curl, domxml, gd, gettext, gmp, iconv, imap, ldap, mcrypt, openssl,
> pgsql, zlib
> 
> Note also: Currently gd is picking up the X11 libXpm, but with some work
> it could be told to find the noX version (and add dependency on that
> package instead.)  That would at least eliminate a dependency on libX11
> for the -gd package, which could save considerable hassle if someone
> didn't want any of the xorg stuff.  Or *gulp* I suppose it might be
> possible to offer both, I think Debian does this.

please noX! if there's no configure switch just patch the X libs away.

> Anyway, I'm getting pretty close to being able to ITP a whole slew of
> stuff but I'd like to get some opinions on some matters first.  Below
> are some issues to consider:
> 
> - mysqlclient.  At the moment I'm compiling the "PHP bundled" MySQL
> client library, but I think it would be better if Cygwin had mysqlclient
> and mysqlclient-devel packages.  That way mod_php could link against
> those, and the issue of "no other Apache modules can use MySQL if you
> use the bundled php version" is solved.  I'll take a look at packaging
> this as well, I've read that the -client packages compile cleanly.  I
> don't think the -server side builds clean yet though.

server builds clean also, but runs not very good.
having mysqlclient and mysqlclient-devel is a VERY good idea.

> - versioning: Apache 1.3 vs 2.x and php4 vs php5.  For apache, I had
> planned to just adopt the "apache" = 1.3 and "apache2" = 2.x method.  So
> /etc/apache/*.conf, /usr/lib/apache/mod*.dll, /usr/share/apache, etc. 
> And when 2.x is ready, /etc/apache2/*.cond, /usr/lib/apache2/*, etc. 
> Contrast to Debian which has /usr/lib/apache/{1.3,2.0}.  

perfect.

> For php I've
> used "php4" throughout, so /etc/php4/*.ini, /usr/lib/php4/*, and so on. 
> If/when php5 is ready I think it should co-exist with s/php4/php5/ in
> the names.

php4 and php5?
I would prefer /usr/lib/php and /usr/lib/php5
but I have not a strong opinion on that.
just most apps expect /usr/local/php/lib/php.ini and /usr/php/lib/php.ini
/etc/php.ini and /etc/php5.ini is also okay.

cgi in /usr/lib/php/bin/php.exe or /usr/bin/php.exe ?
cli / cgi seperation?
then it must be /usr/lib/php/bin/php.exe (cgi) and
                 /usr/bin/php.exe (cli)

> - Package naming.  We already have "apache" and I was planning on
> "mod_php4" for the main PHP module.  Alternatives: libapache-mod_php4,
> apache-php4, apache-mod_php4, etc.  Same for mod_ssl and other Apache
> modules.  And the question still remains what to call the additional PHP
> extension packages, as any of the extensions from the group in C) above
> can be made its own package.  So for example we could offer a
> "mod_php4-pgsql" package that would add postgres support.  Some of them
> though don't really deserve their own package, I mean I think it would
> be safe to require bzip2 and zlib and not offer them as individually
> selectable modules.

I like this most:
apache{,2}-php4
libhttpd-php4
php{4,5}-cli (for the cgi and cli and pear)
php4{4,5}-extensions

apache-mod_php4 is quite a long name but also good.
if you really want that many packages to maintain :)

apache-ssl should really be a seperate package, since this requires the 
ugly mod_ssl EAPI patch AND the rebase problems.

less packages:
apache-php4 (incl. pear + cli + exts)
apache-php5 (incl.  pear + cli + exts)
libhttpd-php4
apache2-php4 (incl. pear + cli + exts)
apache2-php5 (incl. pear + cli + exts)

this way most other distribs do it.

pear could be shared between php4 and php5

> Or, there could just be the single mod_php4 package, but only the
> modules from C) that correspond to installed packages are enabled in the
> postinstall, so that they don't pull in a bunch of stuff in the
> "requires" line.  Under that scenario if you wanted to e.g. add postgres
> support you would install the postgres package, then reinstall mod_php4
> (or re-run its module config script) and the pqsql module would be
> automagically activated.  I can see pros and cons to both ways of doing
> it - what do you think?

if postgresql provides the needed dll,
just edit php.ini to activate this particular extension, which is
either in apache-php4 or php4-extensions.
I don't like to much magic postinstall stuff, but if it works :)

> Also in this category is the CLI version of PHP (which I'm not building
> at the moment) as well as PEAR.  They could be offered as seperate
> "php4-cli" and "php4-pear" packages.  However I'm not entirely sure how
> the extensions would work there: I /think/ but am not sure that they
> would share the same extensions (the Apache module and /usr/bin/php4
> that is.)

yes, pear should be shared. extensions also. and you don't need to 
bundle them twice. either in the cli or the main apache package is enough.
FYI: the extensions path is pulled from the php.ini, which location is 
compiled in. so mod_php4 and php.exe will find it.
the extensions filename is in php.ini. most unix packages don't enable 
the extensions, but most windows do so.

ext filenames: best is to leave them as the native windows build: 
php_pdflib.dll, so that php.ini doesn't need to be patched.
but this could clash with the win32 native parts, so one could also name 
them .so, and import them via dlopen("php_gd.so") in apache at run-time 
(unix style).
unix prefers dlopen, windows prefers loading at startup via extension=.

I would choose .dll as extension.
they do work in the seperate extensions dir, even on windows.

> I'm sure there are other issues, but those are the ones that come to
> mind right now... I'm just trying to get some concensus here first
> before posting "-1" packages that end up needing to be recreated.  All
> comments welcome.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/



More information about the Cygwin-apps mailing list