php5 +apache installation workaround
ryandesign at macports.org
Mon Dec 18 09:20:22 PST 2006
Please keep this discussion on the list by using the Reply To All
feature of your mail program.
On Dec 18, 2006, at 10:50, js wrote:
> Hi Ryan,
> Thank you for your reply.
> On 12/18/06, Ryan Schmidt wrote:
>> I am the maintainer of the php5 port. I have not worked on the
>> problem because I have never observed it. I use php5 +apache2, not
>> php5 +apache. When I have a moment I will try to install php5
>> +apache. If there's anything else I need to do to recreate the
>> problem on my system, please tell me what.
> No idea. I didn't try +apache2, so +apache might be the culprit.
>> -DBIND_8_COMPAT=1 presumably gives you compatibility with bind 8?
>> What is bind, what version would we otherwise have compatibility
>> with, and why is 8 better? Is there documentation to support your
>> What does -DEAPI do?
>> Isn't -O3 simply adding additional compiler optimization? If so, it
>> should have no relevance to the problem you are experiencing. Whether
>> to add -O3 should then be considered separately of this problem. (If
>> it is of benefit to php5, is it also of benefit to the rest of the
>> ports? If so, should it be enabled separately? Etc.)
>> Ah, I see now, you're just quoting the bug report, which is quoting a
>> user comment on this page:
>> Unfortunately those user comments do not explain themselves very
> You're right. I just read that page and created tha patch, so I'm
> not sure
> what EAPI really is but today I googled for it and figured out that
> Apple's apache is compiled with EAPI support but MacPorts's is not.
> $ /opt/local/sbin/httpd -V | grep -i EAPI
> $ /usr/sbin/httpd -V | grep -i EAPI
> -D EAPI
> When you compile a module for apache compiled with EAPI,
> you need to tell the module of the fact .
> (Another quotation from
> So if you use MacPorts's apache, probably you don't need -DEAPI, but
> you might want -DEAPI if you use Apple's. (Not tested.)
Interesting! Thanks for looking that up.
>> This is a second issue (which unfortunately seems to be mentioned in
>> the same MacPorts bug report). It changes the php5 +apache variant.
>> Currently, php5 +apache uses Mac OS X's provided Apache server. After
>> these changes, it would use the MacPorts apache port. There has in
>> the past been a request to offer both variants: a way to install
>> using Apple's Apache, and a way to install using MacPorts' Apache. I
>> would be in favor of a patch to implement this suggestion. I would
>> like to see precedent for other ports that have options both for
>> using Apple's version of something and the MacPorts version, and I
>> would like to then follow the same variant naming conventions.
>> Someone interested in seeing such a patch applied should do this
>> research and report back.
> To me that change seems wrong idea, I'm afraid.
> As you said in the other mail,
> "MacPorts philosophy has always been to
> build its own versions of software, and not use any versions Apple
> may already have installed with the OS"
> If so, why don't you use MacPorts's one by default?
By "by default" do you mean "when you use the +apache variant"? If
so, I agree with you, from the other thread you quoted. However, I
wanted to note that this seems to be a completely separate issue from
the one you originally mentioned.
> besides, who want to use Apple's old, not so well maintananced
A month or two ago, I proposed eliminating the ability to use Apple's
Apache and only use MacPorts's Apache. Several people objected to
this, which is why I proposed the compromise in which both are
Some reasons to prefer Apple's are that it gets auto-upgraded by
Software Update, and that you can control it from System Preferences
> Sharing > Personal Web Sharing. With the MacPorts version, you
have to use the terminal for both tasks, something some users are not
More information about the macports-users