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.
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
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
Configure scripts for extensions look for PDO include files in
$prefix/include/php. This change makes them look into $phpincludedir
instead, which may be different from $prefix/include/php.
Linux are now used. DTrace is part of Oracle Linux. See
https://oss.oracle.com/projects/DTrace/
This patch does not change DTrace linking for non-Solaris/Linux
platforms.
For SystemTap users on Linux, this patch removes the compilation
warning:
Warning: Linking the shared library libphp5.la against the
non-libtool objects Zend/zend_dtrace.d.o is not portable!
Configure runs like:
$./configure -C CFLAGS="-ggdb" --enable-debug --prefix=$(pwd)/usr
did result in an empty config.nice
* allow single dash flags like -C, -s etc.
* allow passing evnironment variables as arguments
Peter Kokot
Dmitry Stogov
Jakub Zelenka
Remi Collet
Ondřej Surý
Joe Watkins
Michael Orlitzky
Kalle Sommer Nielsen
Nikita Popov
Xinchen Hui
Michael Wallner
Bob Weinand
Levi Morrison
Maxime BESSON
Anatol Belski
krakjoe
Florian MARGAINE
Veres Lajos
Remi Collet
Christopher Jones
David Soria Parra
Adam Harvey