Date: Sat, 24 Jul 2004 15:52:39 -0500 From: "antenneX" <antennex@swbell.net> To: "Drew Marshall" <drew@themarshalls.co.uk> Cc: freebsd-questions@freebsd.org Subject: Re: Installing php4 Message-ID: <009901c471c0$2866ecf0$0200000a@SAGEAME> References: <41022833.6090509@themarshalls.co.uk><41022D4E.8040307@circlesquared.com><20040724104531.GC91096@happy-idiot-talk.infracaninophile.co.uk> <4102C399.4030707@themarshalls.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Drew Marshall" <drew@themarshalls.co.uk> Cc: <freebsd-questions@freebsd.org> Sent: Saturday, July 24, 2004 3:16 PM Subject: Re: Installing php4 > Matthew Seaman wrote: > <snipped> > > >Actually, php4-extensions works with any of the 'main' PHP ports -- > >lang/php4, lang/php4-cli, www/php4-cgi or www/mod_php4. The fact that > >there are 4 different variations on a plain 'php4' port in the tree is > >the reason why all of the module support was moved out into a separate > >extensions port. > > > >While this move to specifying all of the PHP modules as loadable > >extensions makes a great deal of sense from one point of view -- ports > >that use PHP can now explicitly list all of the extensions they > >require to operate, rather than having to have their own private PHP > >slave ports -- the implementation has run into a number of problems. > > > >For php4 there are some extensions where the same functionality is not > >available when used as a loadable module as when compiled in. The > >security/php4-openssl extension is a case in point: unless OpenSSL > >support is compiled-in, the fsockopen() function won't let you open > >'tls://' or 'ssl://' style URLs. (As a practical result, that means > >that eg. Squirrelmail can't communicate with a secure IMAP server on > >port 993. The only alternative in that case is to communicate to an > >unencrypted IMAP server on port 143, which quite probably involves > >sending passwords over the net in plaintext.) > > > >Beyond that, not all of the PHP consuming ports have yet been updated > >to depend on the appropriate PHP extensions, so installing those ports > >de novo doesn't immediately get you a workable system. A common > >symptom of this is a run-time error where one of the perl compatible > >regular expression (pcre_*()) functions doesn't work. The answer > >pretty much is just to install the required extension modules by hand, > >and tweak the value of the 'extension_dir' directive in > >/usr/local/etc/php.ini > > > > > > > I understand the logic but I would have thought a line somewhere in > Makefile or the README just to give poor stupid people like me a clue as > to where to start looking. Ons further question that has come from my > compilation of the php4-extension is that once you have made your > selection the first time these options seem to be saved somewhere (The > build process states found previous configuration or similar) where is > this? I missed an option in my hurry this morning and now can't get back > to the menu options (No matter how many make cleans, pkg_deletes etc I > do) to re-set or add the options. > > Many thanks for being so helpful > > Drew > Look at /var/db/ports/* and then delete any option files that pertain to php4. That will allow the menu to come up again on a fresh make.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?009901c471c0$2866ecf0$0200000a>