Pre-ITP: apache/mod_php
Reini Urban
rurban@x-ray.at
Fri Sep 24 14:26:00 GMT 2004
Brian Dessent schrieb:
> Reini Urban wrote:
>>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
>
>
> You keep mentioning this split, between cygphp4.dll and mod_php4.dll but
> you either must be making it up or it's something new in php5. The php4
> build system generates no such thing, nor can I see a way to make it do
> so. The build system builds the SAPI DSO (cygphp4.dll / libphp4.so) and
> the binary (php.exe / php), with no intermediate common libraries. I
> see no way to make it do what you say above.
no, this was my own custom php4 build and if I remember correctly on
suse also. on windows (MSVC) for sure.
just /usr/local/lib/libphp4.so of course.
we'd need our intermediate /usr/lib/libphp4.dll.a and .la also.
but you are right: my latest php builds on unix also give me just static
cli and cgi's (7.5 MB stripped)
having the static cgi and cli exe is also ok, if you don't mind the huge
redundant size for all.
# ldd /usr/local/bin/php
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4001b000)
libexpat.so.0 => /usr/local/lib/libexpat.so.0 (0x40048000)
libmm.so.13 => /usr/local/lib/libmm.so.13 (0x4006c000)
libpq.so.3 => /usr/local/pgsql/lib/libpq.so.3 (0x40071000)
libmhash.so.2 => /usr/lib/libmhash.so.2 (0x40139000)
libmcrypt.so.4 => /usr/local/lib/libmcrypt.so.4 (0x4015c000)
libdl.so.2 => /lib/libdl.so.2 (0x40163000)
libltdl.so.3 => /usr/lib/libltdl.so.3 (0x40167000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x4016e000)
libz.so.1 => /lib/libz.so.1 (0x401a0000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x401af000)
libdb-4.2.so => /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so
(0x401ce000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40278000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4027f000)
libm.so.6 => /lib/libm.so.6 (0x40292000)
libnsl.so.1 => /lib/libnsl.so.1 (0x402b4000)
libcurl.so.3 => /usr/local/lib/libcurl.so.3 (0x402ca000)
libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x403a7000)
libpthread.so.0 => /lib/libpthread.so.0 (0x404b5000)
libc.so.6 => /lib/libc.so.6 (0x404cb000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
for apache2 and lighttpd we must make our own php libs then, with the
same configure quirks. that's what I wanted to avoid with the general
cygphp4.dll
> Here is the quick summary of how Debian has packaged php4. I like to
> default to Debian in terms of questions of paths and packages, since I
> know they have put a great deal of thought into offering multiple
> versions (they simultaneously support 3.x, 4.x, and 5.x) and they try
> hard to adhere to the FHS.
>
> php4:
> depends: (libapache-mod-php4 or libapache2-mod-php4
> or caudium-php4) php4-common
> files: none
> php4-common:
> depends: none
> files: /usr/share/doc/php4-common/* /etc/cron.d/php4
> php4-cgi:
> depends: php4-common php4-cli
> recommends: php4-pear
> suggests: phpdoc
> files: /usr/lib/cgi-bin/php4 (2.7MB, no other php lib dependencies)
aha, but the extensions must be somewhere. they are opened via dlopen.
So I miss the "recommends: extensions"
# php -m
[PHP Modules]
ADOdb
ctype
curl
dba
domxml
gd
gettext
iconv
mbstring
mcrypt
mhash
mysql
openssl
overload
pcre
pgsql
posix
session
standard
tokenizer
xml
xmlrpc
zlib
> php4-cli:
> depends: php4-common
> recommends: php4-pear
> suggests: phpdoc
> files: /usr/bin/php4 (2.7MB, no other php lib dependencies)
same.
> php4-pear:
> depends: php4-common php4-cli
> suggests: php4-dev
> files: /usr/bin/pear /usr/share/php/* (PEAR stuff)
> php4-dev:
> depends: php4-common
> files: /usr/bin/{ext_skel,php-config,phpextdist,phpize}
> /usr/include/php4/* /usr/lib/php4/{build,skeleton}/*
> libapache-mod-php4:
> depends: php4-common
> suggests: php4-pear phpdoc
> files: /usr/lib/apache/libphp4.so
> phpdoc:
> depends: none
> files: /usr/share/doc/phpdoc/* (php manual in html)
>
> configs:
> /etc/php4/apache/php.ini
> /etc/php4/cgi/php.ini
> /etc/pear/pear.conf
>
> extensions:
> /usr/lib/php4/20020429/*.so
>
> I know that this deviates from the "stock PHP way" in a number of
> aspects. However, the more I learn about it the more I loathe the
> "stock PHP way" as it's just broken.
ok. as long as it works and noone is worried about the size.
you are the maintainer.
> For the purposes of Cygwin, I'm not sure if I want that number of
> seperate packages. What I had in mind was a single package for the CLI
> binary, headers, build stuff, PEAR, and possibly a postinstall that
> installs it as a CGI if you don't have mod_php4 installed. I don't know
> whether I'd call this "php4" or "php4-cli". And I think I'll skip
> including the entire manual, you can get that from their site.
>
>>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.
>
> I already posted my first set of patches to the other thread on main
> cygwin list. Attached is a better version, it eliminates a couple of
> redundant changes I made, and uses the noX libXpm if present.
thanks.
you might consider this patch also. it fixes the dba quirks with
berkeley. (move LIBS after conftest.c)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: php-dba.patch
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20040924/8d78afe1/attachment.ksh>
More information about the Cygwin-apps
mailing list