Date: Sat, 24 Jul 2004 22:50:15 +0200 From: Hasse <hasse@swedehost.com> To: freebsd-questions@freebsd.org Cc: Peter Risdon <peter@circlesquared.com> Subject: Re: Installing php4 Message-ID: <200407242250.15681.hasse@swedehost.com> In-Reply-To: <4102BF57.1080308@themarshalls.co.uk> References: <41022833.6090509@themarshalls.co.uk> <20040724104531.GC91096@happy-idiot-talk.infracaninophile.co.uk> <4102BF57.1080308@themarshalls.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 24 July 2004 21.58, Drew Marshall wrote: > 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 ----------------------- Hi. I had a hard time after a upgrade too. Had to comment out 'extension_dir' directive in /usr/local/etc/php.ini just to get it to work at all. ( Running a PhpNuke site :-) What I understand, from the mailinglist, the 'extension_dir' are allready hardcoded in the php-source. So if you override it in php.ini, you have to give it the correct location. I also had to deinstall the allready installed packages from my previous attempt. ( I made a bad choice ) pkg_delete -r php4\* You might try looking for the options in /var/db/ports/php4-extensions/options Hope this helped. /Hasse.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407242250.15681.hasse>