This selection of suppressed warnings is pretty arbitrary, and
apparently disabling it does not raise any more warning for whole
php-src (except for `-Wno-deprecated-declarations`). As such it
appears to be pretty useless, and it seems to be more appropriate to
let users select which warnings to suppress via manually set `CFLAGS`.
Since we already apply `/wd4996`[1] when building with MSVC, and there
are indeed plenty of deprecation warnings, for now, we apply
`-Wno-deprecated-declarations` for Clang builds unconditionally.
[1] <https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996>
Closes GH-17554.
On Windows, the cli and phpdbg SAPIs have variants (cli-win32 and
phpdbgs, respectively) which are build by default. However, the
variants share some files, what leads to duplicate build rules in the
generated Makefile. NMake throws warning U4004[1], but proceeds
happily, ignoring the second build rule. That means that different
flags for duplicate rules are ignored, hinting at a potential problem.
We solve this by introducing an additional (optional) argument to
`SAPI()` and `ADD_SOURCES()` which can be used to avoid such duplicate
build rules. It's left to the SAPI maintainers to make sure that
appropriate rules are created. We fix this for phpdbgs right away,
which currently couldn't be build without phpdbg due to the missing
define; we remove the unused `PHP_PHPDBG_EXPORTS` flag altogether.
[1] <https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/nmake-warning-u4004>
Closes GH-17545.
First, more recent versions of Clang do no longer have trailing info in
parentheses, so the detection would fail. Since we're not interested
in this information, we just ignore it.
Then we should not rely on Clang being installed in the default program
folder. Instead we look up where the first clang.exe can be found, and
assume that it is located in a bin/ folder in the installation path.
From there we construct the library path, which is
`lib\clang\<ver>\lib\windows` where `<ver>` is either the full version
(older Clang) or only the major version. Note that this is the case
for stand-alone LLVM installations as well as Visual Studio supplied
ones.
Finally, we clean up by improving the error messages, and removing the
duplicate clang version detection in `add_asan_opts()`.
While we're at it, we also apply a cosmetic improvement to avoid
(trailing) whitespace in the compiler name (e.g. shown by `-v`).
For Clang, we just need to define the respective macros, since these
built-ins are available in all supported Clang versions (>= 4.0.0,
currently)[1].
For MSVC (and possibly other compilers) we use the respective APIs of
intsafe.h[2] which are available as of Windows 7/Server 2008 R2.
This avoids the UB due to signed integer overflow that may happen with
our fallback implementations.
We also drop the superfluous SHORT_MAX definition from pdo_firebird.
This shouldn't be defined unconditionally, but since it is apparently
unused, we remove it altogether.
[1] <https://releases.llvm.org/4.0.0/tools/clang/docs/LanguageExtensions.html>
[2] <https://learn.microsoft.com/en-us/windows/win32/api/intsafe/>
phpize builds on Windows ignore the paths of extension sources, and
build all object files in the same folder. This can't work if there
are multiple source files with the same base name stored in separate
folders and registered as such (e.g. cls/worker.c and src/worker.c).
While extension authors can work around by avoiding duplicate base
names, they may not even be aware of the problem because on POSIX
systems, the object files are usually placed right besides the sources.
Thus we take the relative path (from `configure_module_dirname`) of the
source files into account even for phpize builds. Since this may break
some extension builds (especially those which use Makefile fragments),
we do not apply this fix to stable branches.
Closes GH-17016.
Besides that is generally good practice to avoid macro redefinitions
(and symbol redeclarations), and we're doing this on POSIX platforms
anyway, there is a particular issue regarding phpize builds, where
config.w32.h actually includes config.pickle.h. The latter overrides
some macro definitions (e.g. `PHP_BUILD_SYSTEM`) to define the proper
values, but if config.w32.h is included multiple times, different macro
definitions eventually raise C4005 compiler warnings[1], which break
builds with `/WX /W1` enabled.
[1] <https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4005>
While it is already possible to enable ASan for MSVC (assuming Visual
Studio 2019 16.10 or later) by passing `/fsanitizer=address` in the
`CFLAGS`, it is only usable if `ZEND_DEBUG` is also enabled; otherwise
there are `STATUS_BACK_STACK` errors all the time.
Since it makes some sense to combine ASan instrumentation with debug
assertions enabled anyway (typical for fuzzing), we support the
configure option `--enable-sanitizer`, which is already supported for
Clang builds, also for MSVC builds. Note that MSVC supports only ASan
for now; contrary to Clang which additionally supports UBSan on Windows.
Since ASan reports can be pretty useless without debug symbol
information, we require such builds to also produce PDBs (i.e.
`--enable-debug-pack`), but forbid actual debug builds (for performance
reasons, and because the way it is implemented it would not make sense;
that was already an issue with Clang builds with sanitizers enabled).
Closes GH-16999.
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.
