The configure script already warns users at the beginning with
unrecognized options warning so additional check is not required. These
sapis were also removed from the PHP core.
Usage of VLA is not portable, wile supported by some compilers. For
instance, GCC supports it even if -std=c89 is passed. Even if we would
switch to C99, it would be still not portable at least with VC++. Thus,
adding a centralized check so such code can be guarded and moved to
alloca() if needed.
As described in bug report #75722, the configure script (acinclude.m4)
currently searches for the valgrind header file and enables valgrind
support if found.
When cross-compiling the searched paths are invalid for the target
platform because they belong to the host system. At the moment, there is
no way to tell the build system a dedicated path where to look for the
header file.
This leads to the issue, that when cross-compiling eg. for ARMv5 platform,
that valgrind header file is detected - e.g. because host system is amd64 -
and support is enabled - but target platform will never support valgrind
(valgrind requires e.g. at least ARMv7).
This change reworks the detection so that user could manually opt-in
valgrind support and optionally specify a directory where the build system
should look for the header file using the --with-valgrind option.
apache2filter was supported in PHP <= 5.6. This patch removes some old
apache2filter occurrences. Also FreeBSD warning therefore is not needed
anymore when building PHP with apache2filter and in later versions don't
need to set the --with-tsrm-pth option.
configure.ac was introduced in 2001 with automake-1.15 and autoconf-2.50
to replace the file named configure.in.
Autotools is preparing to remove configure.in in Automake 2.0.
All new software should be using configure.ac.
This also fixes Bug #69770 where extensions are creating configure.in
Signed-off-by: Brian Evans <grknight@gentoo.org>
If this does not break the Unix system somehow, I'll be amazed. This should get most of it out, apologies for any errors this may cause on non-Windows ends which I cannot test atm.
The existing check for -fvisibility=hidden support came from a time
when only GCC had it. The test for it used a regular expression to
parse the GCC major version from the output of `$CC --version`, and
would look for version 4 or greater.
The regular expression used to accomplish this is doomed, however,
since GCC can be built with a custom version string
(--with-pkgversion). Moreover, the $CC variable can be set to
something that confuses it but is otherwise valid. For example, it
would fail with CC=x86_64-pc-linux-gnu-gcc.
This commit fixes two aspects of the feature test. First, it no longer
limits the test to GCC. At least clang now supports the flag, and can
make use of it when GCC is its backend. Second, support for the flag
is tested directly, by attempting to pass it to the compiler, rather
than by parsing its version string. The latter is accomplished with a
new macro, AX_CHECK_COMPILE_FLAG, taken from the autoconf archive.
The new macro has been added to acinclude.m4, and the test stanza in
configure.in has been replaced with a single call to the new macro.
Note that the new macro calls AC_PREREQ(2.64) -- a more stringent
requirement than the existing AC_PREREQ(2.59) in configure.in. The
difference represents about six years of autoconf releases, from v2.59
in December of 2003 to v2.64 in July of 2009.
This problem was noticed by Brian Evans, who also suggested the fix.
PHP-Bug: 73062