Note that this function is similar to `SETUP_OPENSSL`, but since the
zlib headers are not necessarily required, we append `_LIB`.
We are also more liberal regarding zlib(_a).lib, because
extensions requiring zlib are looking only for zlib.lib if ext/zlib has
been built as shared extension. This is overly restrictive at best,
and actually makes no sense, since (a) we're not shipping shared zlib
builds for years, and (b) users could have a zlib.lib which is a static
build (they could even just rename zlib_a.lib to zlib.lib).
* Don't fiddle with NDEBUG in C code
It is way to late to do this in php.h, since assert.h has already been
included. Even pushing that down to zend_portability.h may not have
the desired effect. Instead we define or undefine NDEBUG as CFLAG, so
that it works in all circumstances.
As a last resort we fail at build time, if `NDEBUG` is defined when
`ZEND_DEBUG` is enabled.
We also remove the useless workaround in zend_test to include assert.h
again, since that usually won't have any effect anyway.
Co-authored-by: Arnaud Le Blanc <arnaud.lb@gmail.com>
While these "macros" work perfectly fine in confutils, it is somewhat
strange to have these two there, while all others are in config.w32
files.
In particular, there is no need for a `MODE_PHPIZE` guard, since there
are already config.w32 and config.w32.phpize.in.
However, we need to replace the semicolon in the helptext, because the
regex which parses ARG_(ENABLE|WITH) calls is restricted, and does not
accept semicolons.
Whether we link with a debug runtime or a normal runtime is not really
related to `PHP_DEBUG`, but rather to `_DEBUG`[1].
We also stop defining that flag, since the compiler already does that.
[1] <https://learn.microsoft.com/en-us/cpp/c-runtime-library/debug>
This function is only available as of Windows 8 and Windows Server 2012,
respectively, and thus needed a fallback (albeit a non working one).
However, as of PHP 8.3.0 Windows 8/Server 2012 is required anyway, so
we can drop the fallback as well as the dynamic loading in favor of
linking to the import library.
For `phpize` builds, all three version variables are numbers, but for
`buildconf` builds, all are strings. This can yield surprising results
when extensions create their `PHP_VERSION_ID` like
10000 * PHP_VERSION + 100 * PHP_MINOR_VERSION + PHP_RELEASE_VERSION
Since `phpize` builds are way more common for external extensions
nowadays, we change the types for `buildconf` builds.
Closes GH-16247.
The dl_test extension is not supposed to be loaded via php.ini
settings, so we exclude it from the typical case on Windows where
`--enable-test-ini` is enabled by `--enable-snapshot-build`.
This is not necessarily useful for Windows (few use custom builds on
that platform), but for feature parity with other platforms it seems
reasonable to support it on Windows.
We make sure, though, that the feature is not enabled for snapshot
builds by adding the option to the build exclusions.
`PHP7DLLTS_EXPORTS` is not used throughout php-src, and it's unlikely
that it is used by any extension, especially since it still refers to
PHP 7. The symbol had been introduced in 2014[1], but is not even used
in latest PHP-7.4; probably it was just supposed to be used, or part of
phpng.
[1] <fc734cf95d>
Since CI already ran for the PR, we can now [skip ci].
"Since limited support for `/arch:AVX512` was added in Visual Studio
2017, and expanded in Visual Studio 2019"[1], we can safely offer this
option, since PHP 8.4 is supposed to build with Visual Studio 2022, and
it is unlikely that someone tries to build PHP 8.4 with Visual Studio,
requesting AVX-512 support.
[1] <https://learn.microsoft.com/en-us/cpp/build/reference/arch-x64?view=msvc-170>
Previously the CHECK_HEADER_ADD_INCLUDE function defined the
`HAVE_<header>_H` preprocessor macros to value 0 or 1 whether the
`<header.h>` file was found. This syncs it with Autotools build system
where most of these macros are either undefined or defined to 1.
In possible edge cases where such macros might be intentionally used
like this without being aware that HAVE_HEADER_H can be 0 or 1 on
Windows:
| #ifdef HAVE_HEADER_H
| ...
| #endif
there is backwards incompatibility for PECL extensions in case the
header wouldn't exist on Windows such code wouldn't execute. However,
this is considered a bug if such case is present. From the Autotools
point of view, the check is correct though and should be used with
ifdef/defined() checks.
Help text is also synced to Autotools style:
`Define to 1 if you have the <header.h> header file.`
* Explicitly drop support for old clang versions on Windows
This ensures compatibility with the typedef redefinitions we use, and
makes it clear during the `configure` stage that old compiler versions
are not supported.
See <https://releases.llvm.org/> regarding the release history of clang.
We also remove support for two number versions of clang, since as of
LLVM 4.0.0 the project uses a three number versioning scheme; see
<https://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html>.
From the documentation[1]:
| We're updating the Microsoft C++ preprocessor to improve standards
| conformance, fix longstanding bugs, and change some behaviors that
| are officially undefined. We've also added new diagnostics to warn
| on errors in macro definitions.
Thus it appears to be sensible to switch to the new preprocessor for
all VS17 builds. Note that although the new preprocessor is available
as of VS16.5 (i.e. `version >= 1925`), we don't want to potentially
break older builds, and as such use the new preprocessor only for VS17
builds. Users who wish to use the new preprocessor with VS16, can
still `set CFLAGS=/Zc:preprocessor` before running `buildconf`/`phpize`.
[1] <https://learn.microsoft.com/en-us/cpp/preprocessor/preprocessor-experimental-overview?view=msvc-170>
Closes GH-15201.
"Since limited support for `/arch:AVX512` was added in Visual Studio
2017, and expanded in Visual Studio 2019"[1], we can safely offer this
option, since PHP 8.4 is supposed to build with Visual Studio 2022, and
it is unlikely that someone tries to build PHP 8.4 with Visual Studio,
requesting AVX-512 support.
[1] <https://learn.microsoft.com/en-us/cpp/build/reference/arch-x64?view=msvc-170>
PR #13498 bumped the required OpenSSL version to 1.1.1, but apparently
only for non Windows system. We catch up somewhat by dropping support
for OpenSSL < 1.1.0 on Windows; besides completely removing detection
of old OpenSSL versions in `SETUP_OPENSSL`, we also ensure that all
bundled extension using this function do no longer accept OpenSSL <
1.1.0, to avoid to still be able to build these extensions with older
`phpize` scripts.
We do not cater to `--phar-native-ssl` yet; that might better be
addressed by #14578.
Closes GH-14973.
As of Visual Studio 2015, the major version of the compiler (`cl.exe`)
is 19, and the minor version increases by steps of 10. However, the
latest Visual Studio 2022 release has the version `19.40`, so that
Visual Studio version is not properly detected. This is not a big deal
regarding the reported compiler version (`php -v` etc.), but the
filenames of the builds would no longer match the expectations (instead
of `vs17` there is now `19.40.33811` or another build number). This
implies that the files would have to be renamed manually to be properly
handled by windows.php.net (or that code would have to be adapted).
Therefore we update the version detection to detect all versions < 1950
as Visual Studio 2022, assuming that "For major releases, the minor
version increases by 10."[1] still holds in the future.
[1] <https://learn.microsoft.com/en-us/cpp/overview/compiler-versions?view=msvc-170#visual-studio-2017-and-later>
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.
This enables outputting additional debugging messages when running
phpdbg for developing and troubleshooting phpdbg itself. Option was
already added in Autotools and this adds it also to Windows build
system.
Because additional info is printed when running tests, the
--enable-phpdbg-debug option is excluded when building with
--enable-snapshot-build if not provided explicitly.
Automatically generating and using test INI files is supported for
in-tree build (`buildconf`) for a long time, and this can make sense
for phpize builds too, especially when the build extension is a zend
extension, so it can be properly loaded.
Thus we make `--enable-test-ini` and `--with-test-ini-ext-exclude`
available for phpize, but default to false for full BC.
Closes GH-8787.
On Windows, the contents of the CREDITS files are passed to rc.exe via
the command line. To avoid undesired behavior, we need to escape some
characters, most notably `<` (which is sometimes used in CREDITS to
enclose mail addresses), which otherwise is interpreted as redirection
operator, resulting in the hard to understand "The system cannot find
the file specified."
Even more dangerous is not properly escaping percent signs, which makes
it possible for a malicious CREDITS file to inject the values of
environment variables of the build system into the generated binaries.
This is particularly bad, because as of Windows Vista, the comments can
no longer be inspected via explorer.exe, although the binaries still
contain these comments.
We also cater to double-quotes, which need to be escaped as `\"\"` in
this context.
Closes GH-8767.
Newer MSVC versions support the `inline` keyword, so we do not need to explicitly define it. We also shouldn't define `inline` to `__forceinline`, as we already have `zend_always_inline` to indicate this requirement.
1. Update: http://www.php.net/license/3_01.txt to https, as there is anyway server header "Location:" to https.
2. Update few license 3.0 to 3.01 as 3.0 states "php 5.1.1, 4.1.1, and earlier".
3. In some license comments is "at through the world-wide-web" while most is without "at", so deleted.
4. fixed indentation in some files before |
We must not redefine the version "constants" for phpize builds, because
these have already generated in phpize.js, from where we pass these
variables forward to configure.js.
We also add `PHP_EXTRA_VERSION` and `PHP_VERSION_STRING` to the files
for completeness.
Closes GH-6419.
`configure` for `phpize` builds on Windows creates Makefile and
config.pickle.h and includes the latter via the command line option
`/FI`. That implies that config.pickle.h is always included before
config.w32.h, which means that standard definitions always override
extension specific definitions, while it should be the other way round.
Therefore, we change the inclusion order by including config.pickle.h
at the end of config.w32.h if the former is available, and also make
sure to avoid any potential C4005 warnings by `#undef`ining the macros
before defining them.
Closes GH-6269.
