php5 +apache installation workaround
Hi list. I spent a fair amount of time for installing php5 +apache today. the problem is described in http://trac.macports.org/projects/macports/ticket/2750 It seems no one's working on this (Look at "Last modified 3 months ago") As a workaround, the following patch would be helpful. should be wrong, but works ;) (and don't forget to addd Include /opt/local/etc/apache/extras-conf/*.conf to your httpd.conf) @@ -88,7 +88,7 @@ --without-pear \ --with-freetype-dir=${prefix} -configure.env CFLAGS=-I${prefix}/include/c-client +configure.env CFLAGS="-I${prefix}/include/c-client -DBIND_8_COMPAT=1 -DEAPI -O3" platform darwin 6 { depends_lib-append lib:libdl:dlcompat @@ -124,7 +124,8 @@ depends_lib-append path:${prefix}/sbin/apxs:apache configure.args-append --with-apxs=${prefix}/sbin/apxs } else { - configure.args-append --with-apxs=/usr/sbin/apxs + depends_lib-append path:${prefix}/sbin/apxs:apache + configure.args-append --with-apxs=${prefix}/sbin/apxs } }
On Dec 17, 2006, at 17:12, js wrote:
I spent a fair amount of time for installing php5 +apache today. the problem is described in http://trac.macports.org/projects/macports/ticket/2750 It seems no one's working on this (Look at "Last modified 3 months ago")
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.
As a workaround, the following patch would be helpful. should be wrong, but works ;) (and don't forget to addd Include /opt/local/etc/apache/extras- conf/*.conf to your httpd.conf)
@@ -88,7 +88,7 @@ --without-pear \ --with-freetype-dir=${prefix}
-configure.env CFLAGS=-I${prefix}/include/c-client +configure.env CFLAGS="-I${prefix}/include/c-client -DBIND_8_COMPAT=1 -DEAPI -O3" platform darwin 6 { depends_lib-append lib:libdl:dlcompat
What do these changes do? -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 position? 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: http://www.php.net/manual/en/install.macosx.php Unfortunately those user comments do not explain themselves very much.
@@ -124,7 +124,8 @@ depends_lib-append path:${prefix}/sbin/apxs:apache configure.args-append --with-apxs=${prefix}/sbin/apxs } else { - configure.args-append --with-apxs=/usr/sbin/apxs + depends_lib-append path:${prefix}/sbin/ apxs:apache + configure.args-append --with-apxs=${prefix}/sbin/ apxs } }
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.
Ryan Schmidt <ryandesign@macports.org> on Sunday, December 17, 2006 at 5:20 PM -0800 wrote:
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.
Naming is important. I think "macosx" is a terrible name for a variant because it doesn't mean anything to someone that doesn't already know. I like the snmp variants to php5 as a model. Probably because I contributed them. +snmp +macports_snmp It seems clear to me what each one days. And if it still weren't clear there are the Portfile comments. # This compiles PHP5 with SNMP linked against Apple's included NET-SNMP. # This compiles PHP with SNMP linked against MacPorts' NET-SNMP. Mark
On Dec 17, 2006, at 23:00, Mark Duling wrote:
Ryan Schmidt on Sunday, December 17, 2006 at 5:20 PM -0800 wrote:
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.
Naming is important. I think "macosx" is a terrible name for a variant because it doesn't mean anything to someone that doesn't already know. I like the snmp variants to php5 as a model. Probably because I contributed them.
+snmp +macports_snmp
It seems clear to me what each one days. And if it still weren't clear there are the Portfile comments.
# This compiles PHP5 with SNMP linked against Apple's included NET- SNMP.
# This compiles PHP with SNMP linked against MacPorts' NET-SNMP.
I object to this naming (for the SNMP port as well, I just forgot to say so before) because the 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. This is explained in the FAQ: http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries Therefore, one should be able to assume that a variant uses MacPorts software only, unless otherwise noted. Therefore, I would have the +snmp and +apache variants using the MacPorts versions of that software, and introduce new variants to handle the cases where using the Apple software is desired. (I haven't done research on what other ports like this are doing, but maybe +snmp_apple and +apache_apple.) Incidentally, I'm seeing this question in the FAQ http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhenIinstalltheportofPHP5MacPortswantstoinstallApache1.3eventhoughIu seApache2.WhatdoIneedtodo which suggests that the php5 port already supports all three Apache options: - with the apache2 variant, it builds Apache 2 from MacPorts - with the apache variant, it uses Apache 1 from Apple - with no variant, it uses Apache 1 from MacPorts If this behavior indeed exists (I have not confirmed it), it strikes me as bizarre, and I would want to change it to something more sane and understandable like: - with the apache2 variant, it builds Apache 2 from MacPorts - with the apache variant, it builds Apache 1 from MacPorts - with the apache_apple variant, it uses Apache 1 from Apple - with no variant, no Apache support of any kind is built
Ryan Schmidt <ryandesign@macports.org> on Sunday, December 17, 2006 at 10:57 PM -0800 wrote:
Naming is important. I think "macosx" is a terrible name for a variant because it doesn't mean anything to someone that doesn't already know. I like the snmp variants to php5 as a model. Probably because I contributed them.
+snmp +macports_snmp
It seems clear to me what each one days. And if it still weren't clear there are the Portfile comments.
# This compiles PHP5 with SNMP linked against Apple's included NET- SNMP.
# This compiles PHP with SNMP linked against MacPorts' NET-SNMP.
I object to this naming (for the SNMP port as well, I just forgot to say so before) because the 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. This is explained in the FAQ:
http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries
Therefore, one should be able to assume that a variant uses MacPorts software only, unless otherwise noted.
Though the standards and documentation to which you refer do not impose naming conventions, I do think the names can reflect this and I agree with you. I liked the clarity of the names and the naming method for the snmp variant, I wasn't necessarily enamored of the names themselves.
Therefore, I would have the +snmp and +apache variants using the MacPorts versions of that software, and introduce new variants to handle the cases where using the Apple software is desired. (I haven't done research on what other ports like this are doing, but maybe +snmp_apple and +apache_apple.)
That's what I was thinking too, unless someone else can think of a better name I think that is probably the best way to go.
Incidentally, I'm seeing this question in the FAQ
http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhenIinstalltheportofPHP5MacPortswantstoinstallApache1.3eventhoughIu seApache2.WhatdoIneedtodo
which suggests that the php5 port already supports all three Apache options:
- with the apache2 variant, it builds Apache 2 from MacPorts - with the apache variant, it uses Apache 1 from Apple - with no variant, it uses Apache 1 from MacPorts
If this behavior indeed exists (I have not confirmed it), it strikes me as bizarre, and I would want to change it to something more sane and understandable like:
- with the apache2 variant, it builds Apache 2 from MacPorts - with the apache variant, it builds Apache 1 from MacPorts - with the apache_apple variant, it uses Apache 1 from Apple - with no variant, no Apache support of any kind is built
I think that makes sense. Mark
participants (3)
-
js
-
Mark Duling
-
Ryan Schmidt