Edit report at http://bugs.php.net/bug.php?id=53348&edit=1
ID: 53348
Updated by: srina...@php.net
Reported by: mike at harschsystems dot com
Summary: building with apxs can fail when compiler doesn't
match apr library
-Status: Open
+Status: Feedback
Type: Feature/Change Request
Package: Compile Failure
Operating System: Solaris and others
PHP Version: trunk-SVN-2010-11-18 (SVN)
Block user comment: N
Private report: N
New Comment:
this should be a bug within solaris and not within php because solaris
build
process should not expose the compiler flags within apxs.
please raise a bug within solaris. right way place to do this would be
defect.opensolaris.org
would recommend closing this bug as not a valid bug.
Previous Comments:
------------------------------------------------------------------------
[2010-11-19 00:25:04] mike at harschsystems dot com
Description:
------------
The build system uses the apr-1-config command to retrieve flags from
the apr
library to use for building shared object targets (e.g.
sapi/apache2handler/config.m4). If however, the compiler used to build
the apr
library was different (and supports different flags) than your current
compiler,
you may end up with incompatible compiler flags in your Makefile for
these
targets.
This problem manifests itself in Solaris when trying to build php using
gcc,
while trying to use the binary version of apache shipped with your
distribution
(which was compiled with sun's forte compiler 'cc'). The first symptom
from the
user's perspective is the following compile failure:
mkdir sapi/apache2handler/.libs
cc -DSSL_EXPERIMENTAL -DSSL_ENGINE -I/usr/apache2/2.2/include
-DSOLARIS2=11 -
D_POSIX_PTHREAD_SEMANTICS -mt -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-
I/usr/apr/1.3/include -I/usr/apr-util/1.3/include -
I/wd/builds/sfw/proto/root_i386/usr/include -Isapi/apache2handler/ -
I/var/tmp/php-trunk/sapi/apache2handler/ -DPHP_ATOM_INC -I/var/tmp/php-
trunk/include -I/var/tmp/php-trunk/main -I/var/tmp/php-trunk
-I/var/tmp/php-
trunk/ext/date/lib -I/var/tmp/php-trunk/ext/ereg/regex
-I/usr/include/libxml2 -
I/usr/X11/include -I/usr/include/freetype2 -I/var/tmp/php-
trunk/ext/mbstring/oniguruma -I/var/tmp/php-trunk/ext/mbstring/libmbfl
-
I/var/tmp/php-trunk/ext/mbstring/libmbfl/mbfl -I/var/tmp/php-
trunk/ext/sqlite3/libsqlite -I/usr/include/tidy
-I/var/tmp/php-trunk/TSRM -
I/var/tmp/php-trunk/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g
-O0 -Wall
-c /var/tmp/php-trunk/sapi/apache2handler/mod_php5.c -fPIC -DPIC -o
sapi/apache2handler/.libs/mod_php5.o
cc1: error: invalid option `t'
make: *** [sapi/apache2handler/mod_php5.lo] Error 1
The error is coming from the "-mt" flag, which gcc doesn't understand.
It turns
out, "-mt" is a valid sun forte 'cc' flag. Where did this come from?
Looking
at sapi/apache2handler/config.m4, we see the build system asking apr for
cpp
flags like this:
$ apxs -q APR_CONFIG
/usr/apr/1.3/bin/apr-1-config
$ apr-1-config --cppflags --includes
-DSOLARIS2=11 -D_POSIX_PTHREAD_SEMANTICS -mt -D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64 -I/usr/apr/1.3/include
Asking apr about compiler it's built with shows the problem (it's not
gcc):
$ apr-1-config --cc
cc -m32
In this case, some googling revealed that "-mt" is equivalent to
"-D_REENTRANT",
so manually replacing these flags in the Makefile works around the
problem.
It would be nice if the build system did a check to see if `APR_CONFIG
--cc`
matches the current compiler - and warns you if there is a mismatch.
Also, it
would be nice to have an override switch to specify the flags to use
manually,
rather than deriving them from apr.
Test script:
---------------
This problem is reproducible on solaris when trying to compile php with
gcc, and using --with-apxs2 pointing to an apache binary built with
sun's cc rather than gcc (as is the case if using the ips packages
available for opensolaris, etc).
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=53348&edit=1
