* When configuring extensions, considers the PHPDBG SAPI as CLI thus
allowing e.g. to have the pcntl extension available within PHPDBG.
Signed-off-by: Samuele Kaplun <kaplun@protonmail.com>
Makefiles for PHP extensions generated by phpize expect the PHP_MODULES
to contain a list of libtool .la files so that it can read the $dlname
variable from them by sourcing them in to a shell. On AIX, the code was
setting PHP_MODULES to a list of .so files, which meant the dlname was
blank, preventing the tests from being able to run.
Change the AIX code path in the PHP_SHARED_MODULE macro to match the
output on other platforms, using libtool .la files.
Additionally, ICU >= 59.1 requires C++11, so add the flags. Some
refactoring is needed to comply with the latest recommended build
options, such as automatic icu namespace addition.
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.
This patch fixes configure error on some systems such as Alpine.
```
line 3472: test: =: unary operator expected
```
One of the fixes has been suggested also here already:
https://bugs.php.net/bug.php?id=39835
Thank you for considering merging this.
When building with kerberos support (--with-kerberos), a few libraries
and flags need to be added to various parts of the build system. The
most reliable way to get those flags is through the krb5-config
program that ships with both major implementations of kerberos. The
PHP_SETUP_KERBEROS macro in acinclude.m4 attempts to detect
krb5-config, and use it.
However, there's a bug in that macro. The --with-kerberos parameter
accepts a directory where the kerberos libraries can be found. When a
directory is given, it is stored in the PHP_KERBEROS variable. The
following test,
if test "$PHP_KERBEROS" = "yes" && test -x "$KRB5_CONFIG"; then
thus fails whenever a directory is passed to --with-kerberos, since it
compares a directory name against the string "yes". This causes
krb5-config to go unused, and some unreliable fallback logic is
attempted instead. One consequence of this is that the Heimdal
kerberos implementation cannot be substituted for the MIT one, at
least when a directory is passed to --with-kerberos.
This commit reverses the logic and checks for "$PHP_KERBEROS" != "no".
To confirm that this fixes the issue, one can inspect the "-l" library
flags that get appended to the command-line. On a machine with Heimdal
and the unmodified acinclude.m4, running
./configure --with-openssl --with-kerberos=/usr
will log (for example) to config.log,
configure:18082: checking for krb5-config
configure:18101: found /usr/bin/krb5-config
configure:18114: result: /usr/bin/krb5-config
configure:18450: checking for RAND_egd
configure:18450: cc ... conftest.c ... -lgssapi_krb5 -lkrb5 ...
which are the library names for the MIT implementation. After patching
acinclude.m4 to negate the logic, the same command on the same machine
outputs (to config.log):
configure:18450: cc ... conftest.c -lgssapi -lheimntlm ...
These are the correct library names for the Heimdal implementation.
PHP-Bug: 73214
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.
In commit 086f9ad, I added a new macro AX_CHECK_COMPILE_FLAG from the
autoconf archive. Jakub Zelenka pointed out that the license of the
macro (GPL-3+ with exception) does not agree with the license of PHP
itself (PHP-3.01). We should therefore ship the macro in a separate
file with its own license header. That is allowed and is done for
many other files in the PHP repository.
This commit adds a new top-level "m4" directory and places the
upstream ax_check_compile_flag.m4 file in it. The macro is no longer
inlined; instead, our acinclude.m4 now includes the aforementioned
file with m4_include.
PHP-Bug: 73062
Pull-Request: 2124
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
