[MacPorts] #21281: php5 +apache2 +fastcgi fails if using apache2 +preforkmpm (was: php5 5.3.0_2 undefined symbols _core_globals, _sapi_cgi_activate)
MacPorts
noreply at macports.org
Thu Sep 10 17:01:00 PDT 2009
#21281: php5 +apache2 +fastcgi fails if using apache2 +preforkmpm
--------------------------------------+-------------------------------------
Reporter: james.applemac@… | Owner: ryandesign@…
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 1.8.0
Keywords: | Port: php5
--------------------------------------+-------------------------------------
Comment(by ryandesign@…):
I can now confirm the problem, which only exists when apache2 is compiled
with workermpm and php5 is compiled with both the apache2 and fastcgi
variants. Using either the apache2 or the fastcgi variants by themselves
compiles fine, but together:
{{{
Undefined symbols:
"_sapi_globals", referenced from:
_php_print_info in info.o
_php_print_info in info.o
_php_print_info in info.o
_sapi_cgi_read_post in cgi_main.o
_sapi_cgi_send_headers in cgi_main.o
_sapi_cgibin_getenv in cgi_main.o
_sapi_cgi_deactivate in cgi_main.o
_sapi_cgibin_ub_write in cgi_main.o
__sapi_cgibin_putenv in cgi_main.o
_cgi_php_import_environment_variables in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_sapi_cgi_activate in cgi_main.o
_sapi_cgi_log_message in cgi_main.o
_sapi_cgi_register_variables in cgi_main.o
_sapi_cgi_register_variables in cgi_main.o
"_executor_globals", referenced from:
_php_print_gpcse_array in info.o
_php_print_info in info.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
"_core_globals", referenced from:
_cgi_php_import_environment_variables in cgi_main.o
_cgi_php_import_environment_variables in cgi_main.o
_cgi_php_import_environment_variables in cgi_main.o
_cgi_php_import_environment_variables in cgi_main.o
_cgi_php_import_environment_variables in cgi_main.o
_cgi_php_import_environment_variables in cgi_main.o
_cgi_php_import_environment_variables in cgi_main.o
_cgi_php_import_environment_variables in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
_sapi_cgi_activate in cgi_main.o
_sapi_cgi_activate in cgi_main.o
_sapi_cgi_activate in cgi_main.o
_sapi_cgi_activate in cgi_main.o
_sapi_cgi_activate in cgi_main.o
"_compiler_globals", referenced from:
_main in cgi_main.o
_main in cgi_main.o
_main in cgi_main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1
}}}
To build the php fastcgi binary when the php apache2 module has already
been built, I just issue "make" again, which I assume fails in this case
because the apache2 module was built with Zend Thread Safety ("zts") while
the fastcgi binary is wanting to be built without it ("non-zts"). I could
fix that by using "make clean" before building fastcgi, but it still
leaves the problem that you would be installing different php parts which
are not compatible with one another. In particular, all the php modules
you'd want to install separately would only work for one or the other
(either the apache2 module or the fastcgi binary) but not both because
they would have different extensions directories. And I'm not sure how the
php cli would react either.
My current thought is that I should prevent the installation of the php
apache module if apache has not been compiled with its default workermpm
variant.
I did not test what happens when using apache2's third mpm variant,
eventmpm.
--
Ticket URL: <http://trac.macports.org/ticket/21281#comment:3>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list