Date: Sat, 24 Jul 2004 21:57:13 +0100 From: Drew Marshall <drew@themarshalls.co.uk> To: antenneX <antennex@swbell.net> Cc: freebsd-questions@freebsd.org Subject: Re: Installing php4 Message-ID: <4102CD29.8040602@themarshalls.co.uk> In-Reply-To: <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> <009901c471c0$2866ecf0$0200000a@SAGEAME>
next in thread | previous in thread | raw e-mail | index | archive | help
antenneX wrote: >----- 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. > > Smart. That works, as does "make config" that Grant posted. Very happy bunny :-) Thanks all!! Drew -- In line with our policy, this message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. www.themarshalls.co.uk/policy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4102CD29.8040602>