The --no-generation-date flag is a common re2c flag used in all re2c
invocations. This adds the 2nd optional argument to PHP_PROG_RE2C M4
macro in BC manner to set the default re2c command-line options and sets
the default RE2C_FLAGS similarly on Windows.
The pkg-config (libpq.pc file) was added in PostgreSQL 9.3. This adds a
common setup M4 macro PHP_SETUP_PGSQL to find client PostgreSQL library
libpq on the system with pkg-config. If not found, check falls back to
pg_config to find the libpq and its headers in common locations as
before.
The PGSQL_CFLAGS and PGSQL_LIBS environment variables can override the
libpq installation paths:
./configure --with-pgsql --with-pdo-pgsql \
PGSQL_CFLAGS=-I/path/to/libpq \
PGSQL_LIBS="-L/path/to/libpq -lpq"
Passing manual, non-standard PostgreSQL installation path can be done
with configure option arguments:
./configure \
--with-pgsql=/any/path/to/postgresql \
--with-pdo-postgresql=/any/path/to/postgresql
If this DIR argument (PostgreSQL installation directory or path to the
pg_config) is passed, it takes precedence over the pkg-config, when
installed on the system.
This also removes the unused HAVE_LIBPQ symbol and passing the
PGSQL_INCLUDE and PGSQL_LIBDIR environment variable to configure in
favor of PGSQL_CFLAGS and PGSQL_LIBS.
Instead of the obsolete backticks the recommended $(...) is used when
invoking the pg_config.
Follow-up of GH-4235 (Use PKG_CHECK_MODULES to detect the pq library)
This enables the zlib library (https://zlib.net/) from a single place to
match the minimum required version across the php-src. This provides a
possible simpler version bump in the future. Macro's 2nd and 3rd
arguments can pass additional actions whether zlib library is found or
not for the possible future adjustments in the ext/standard where also
zlib might be required.
Support for pkg-config was introduced in 1.2.3.1.
The minimum zlib version has been bumped to 1.2.3.1
* Bump minimum zlib version to 1.2.11
This is aligned with CentOS 8, which has 1.2.11 in the default packages.
* [skip ci] Move zlib version change to UPGRADING
This matches the OpenSSL style version change notice already done in
this file.
If OpenSSL is not found, the PKG_CHECK_MODULES errors out already. To
not introduce too big of a BC break with possible PECL extensions using
this macro, it is perhaps simpler to remove this non-working argument.
Redundant macro arguments are ignored by Autoconf anyway.
Instead of the PHP_SUBST_OLD, which also adds redundant variables to the
generated Makefile, these two can be done with AC_SUBST to be
substituted in the generated main/build-defs.h header and
scripts/php-config script.
- This checks for a type cookie_io_functions_t and defines the
HAVE_FOPENCOOKIE based on type check result and the fopencookie()
function presence.
- Fixed -Wunused... warnings in config.log on stricter compiler
configurations
- The run check for off64_t is wrapped into AC_CACHE_CHECK for having
the php_cv_type_cookie_off64_t cache variable available to customize
possible cross-compilation edge cases
- Comment about glibcs 2.1.2 removed because also some other earlier
versions provided this type already
This fixes the incompatible pointer type warnings when checking for
reentrant functions declaractions (-Wincompatible-pointer-types) in
config.log. These were not declared on some obsolete systems if
_REENTRANT was not defined. The check is for now left in the code base
but can be transitioned to newer code without checking for missing
declarations or using these otherwise in the future.
Closes GH-14315.
By default compilers may not treat attribute warnings as errors when
encountering an unknown __attribute__, unless some error option is
provided (-Werror=attributes, -Werror=unknown-attributes, -Werror...).
This fixes the check and wraps it into a separate M4 macro to be
extendable in the future if needed. It checks if conftest.err file was
generated by the compilation check when warnings appear. Also, PHP check
is a bit customized by using __alignof__ keyword, so it is left in there
for now to not break existing checks.
* Fix check for newer versions of ICU
The previous test would always trigger, even if the version of ICU
installed didn't require C++17. This was because it incorrectly used
the `test` program, which broke the build on systems without a C++17
compiler.
Tested with macOS 14 and i 7.2.
* Fix broken ICU version check for definition
Same as the previous fix for C++17.
---------
Co-authored-by: Peter Kokot <peterkokot@gmail.com>
This adds all root build directories in one call. PEAR directory is
created only when enabled and duplicated Zend directory creation is
removed, because it was intended for the zend_config.h when building
out-of-source or using the config.status manually before the
PHP_ADD_BUILD_DIR was introduced in the build system.
Bumps the minimum required OpenSSL version from 1.0.2 to 1.1.1.
OpenSSL 1.1.1 is an LTS release, but has reached[^1] EOL from upstream. However, Linux distro/OS vendors
continue to ship OpenSSL 1.1.1, so 1.1.1 was picked as the minimum. The current minimum 1.0.2 reached
EOL in 2018.
Bumping the minimum required OpenSSL version makes it possible for ext-openssl to remove a bunch of
conditional code, and assume that TLS 1.3 (shipped with OpenSSL 1.1.1) will be supported everywhere.
- Debian buster: 1.1.1[^2]
- Ubuntu 20.04: 1.1.1[^3]
- CentOS/RHEL 7: 1.0.2
- RHEL 8/Rocky 8/EL 8: 1.1.1
- Fedora 38: 3.0.9 (`openssl11` provides OpenSSL 1.1 as well)
RHEL/CentOS 7 reaches EOL mid 2024, so for PHP 8.4 scheduled towards the end of this year, we can safely
bump the minimum OpenSSL version.
[^1]: https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/index.html
[^2]: https://packages.debian.org/buster/libssl-dev
[^3]: https://packages.ubuntu.com/focal/libssl-dev
Shared objects of extensions during the *nix build are copied to the
`modules` directory. It is a practice established since the early days
of the PHP build system. Other build systems may have similar concept of
"library destination directory". On Windows, they are put into the root
build directory. Such directory simplifies collection of the shared
extensions during testing, or when running the cli executable at the end
of the build process.
This change ensures that the directory is consistently created in a
single location, for both the primary PHP build process and when
utilizing `phpize` within community extensions.
The AC_CONFIG_COMMANDS_PRE is executed at the end of the configuration
phase, before creating the config.status script, where also build
directories and global Makefile are created.
The pwd is executed using the recommended $(...) instead of the obsolete
backticks. Autoconf automatically locates the proper shell and
re-executes the configure script if such case is found that $(...) is
not supported (the initial /bin/sh on Solaris 10, for example).
autoconf/libtool generating code to test features missed `void` for
C calls prototypes w/o arguments.
Note that specific changes related to libtool have to be upstreamed.
Co-authored-by: Peter Kokot <petk@php.net>
close GH-13732
The PHP_CHECK_GCC_ARG has been already removed in PHP 8.0 and this also
removes the error emitting wrapper.
Patches for the solr and vld extensions have been sent upstream.
The AC_CHECK_FUNCS checks whether the linker sees the function in the
usual libraries, in this case libc. This is a simple trick to also check
existence of belonging headers, since the code uses HAVE_PRCTL and
HAVE_PROCCTL to include headers and call functions.
Instead of the project macro, the sockaddr_storage and sockaddr.sa_len
can be checked with the AC_CHECK_TYPES and AC_CHECK_MEMBERS by including
the sys/socket.h. Some systems (~1988) didn't include the sys/types.h in
the socket.h (obsolete on current systems).
These macros by default define the HAVE_STRUCT_SOCKADDR_STORAGE and
HAVE_STRUCT_SOCKADDR_SA_LEN.
The struct flock is defined in fcntl.h, if system has it. This removes
redundant PHP_STRUCT_FLOCK M4 macro in favor of the AC_CHECK_TYPES,
which by default defines symbol HAVE_STRUCT_FLOCK.
This macro is obsolete in favor of the PHP_ARG_WITH macro. It was once
used in combination with the AC_ARG_WITH macro to determine, whether the
extension has been configured as shared.
PHP_DEFINE was introduced with the PHP 5 build system
9d9d39a0de and then refactored via
350de12bc2.
This was once used to put defined constants into a single file to have
more fine-graned dependencies (atomic includes). Since no known PHP
extension is using this and it makes very little sense to use this, this
M4 macro can be removed in favor of the Autoconf native way using
AC_DEFINE and the usual included files php_config.h and config.h.
- Generated unused include directory removed
- Remove include dir from DEFS
- Remove also include dir from PDO checks
SunOS 4.1.4 from 1994 didn't have fclose declared in standard header
stdio.h. This doesn't need to be checked anymore, as fclose is part of
the C89+ standard and declaration is present on Solaris 10 (SunOS 5.10)
and later.
Global --tag=CC defined in configure.ac is not correct in all cases. For example
linking objects that were compiled from C++ sources needs to be done with C++
compiler, however for link mode libtool will prefer compiler indicated with
--tag.
Fixes GH-12349
The fastcgi code was refactored in
18cf4e0a8a and in_addr_t is no longer
used. The PHP_CHECK_IN_ADDR_T is also obsolete and not recommended way
to discover availability of the type. If needed in the future, the
AC_CHECK_TYPES can be used instead.
As noted in glibc, the cookie_io_functions_t should be used instead of
internal _IO_cookie_io_functions_t.
The _IO_cookie_io_functions_t was once used as a convenience for not
having the cookie_io_functions_t available (glibc <=2.1.1) as noted in
67bb9d1ae2.
Check in the build system was also always setting the
COOKIE_IO_FUNCTIONS_T to cookie_io_functions_t due to a typo. There is
unused variable have_IO_cookie_io_functions_t vs.
have_cookie_io_functions_t.
- COOKIE_IO_FUNCTIONS_T removed
Closes GH-12236
We are experiencing an issue when building PHP with DTrace enabled with
SystemTap (see GH-11847).† The issue is caused by inappropriate use C
preprocessor detected by GNU Autoconf in our “configure” script. C
preprocessor configuration found by AC_PROG_CPP macro is portable only
to run on files with “.c” extension.‡ However, statically-defined tracing
is described by D programs with “.d” extension which causes the issue.
We experience this even on typical Linux distribution with GNU Compiler
Collection (GCC) unless we override the defaults detected by our
“configure” script.
Many major Linux distributions use SystemTap to provide “dtrace”
utility. It relies on both external C preprocessor and external C
compiler. C preprocessor can be customized via CPP environment variable.
Similarly, C compiler can be customized via CC environment variable. It
also allows customization of C compiler flags via CFLAGS environment
variable. We have recently aligned both CPP and CC environment variable
with C preprocessor and C compiler we use to build regular C source code
as provided by our “configure” script (see GH-11643).* We wanted to
allow cross-compilation on Linux for which this was the only blocker. C
compiler flags from CFLAGS_CLEAN macro have already been in place since
versions 5.4.20 and 5.5.4 from 2013-09-18.
We had modified all “dtrace” invocations in the same way to make it look
consistent. However, only the C compiler (CC environment variable) is
necessary to for cross-compilation. There have never been any reported
issue with the C preprocessor. We acknowledge it would be great to allow
C preprocessor customization as well. However, the implementation would
require a lot of effort to do correctly given the limitations of
AC_PROG_CPP macro from GNU Autoconf. This would be further complicated
by the fact that all DTrace implementations, not just SystemTap, allow C
preprocessor customization but Oracle DTrace, Open DTrace, and their
forks do it differently. Nevertheless, they all default to “cpp” utility
and they all have or had been working fine. Therefore, we believe simply
removing CPP stabilizes “dtrace” invocation on Linux systems with
SystemTap and aligns it with other system configurations on other
platforms, until someone comes with complete solution with custom “m4”
and “make” macros, while our build system on Linux with SystemTap
supports cross-compilation.
Fixes GH-11847
Closes GH-12083
† https://github.com/php/php-src/issues/11847
‡ https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#index-AC_005fPROG_005fCPP-1
* https://github.com/php/php-src/issues/11643
With DTrace support enabled during ./configure, our custom Autoconf
macro PHP_INIT_DTRACE creates make rules to generate header and object
files using dtrace utility. SystemTap† implementation of dtrace relies
on other utilities to provide header preprocessing and final object file
compilation. These utilities are configured by common environment
variables with common defaults:‡
* preprocessor from CPP defaults to “cpp”
* compiler from CC defaults to “gcc”
* compiler arguments can be expanded with CFLAGS
This has been in SystemTap since version 1.5 released on 2011-05-23. We
have been setting CFLAGS for dtrace since 717b367 released in versions
5.4.20 and 5.5.4 on 2013-09-18. This change fixed build against
SystemTap. It fixes majority of cases since practically all free Linux
distributions use SystemTap for DTrace-like dynamic tracing and
practically all of them use GCC or compatible compiler suite. However,
this becomes an issue when cross-compiling using GCC because utility
names contain target triplets. Autoconf already handles
cross-compilation well —setting correct CC and CPP make macros
(variables).
Therefore, we simply set CC and CPP environment variables using
respective macros when executing dtrace. Although SystemTap dtrace does
not always use CC nor CPP, we set it every time. SystemTap documentation
does not talk about this at all¶, so it is safer to always set it. We
also follow how we set CFLAGS every time in the past.
Original (or ported) DTrace mainly used on Oracle Linux, Solaris and
macOS ignores these and does not support cross compilation.§
† Well-known dynamic tracing infrastructure for Linux compatible with
statically-defined tracing from DTrace.
‡ https://sourceware.org/git/?p=systemtap.git;a=blob;f=dtrace.in;h=73a6f22e2de072773c692e3fea05c4b8cf814e43;hb=ebb424eee5599fcc131901c0d82d0bfc0d2f57ab
¶ https://sourceware.org/systemtap/man/dtrace.1.html
§ https://docs.oracle.com/cd/E88353_01/html/E72487/dtrace-8.html
Closes GH-11643
