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.
Checking the linker compatibility with extranous `ImageLoad()` calls is
possible, but unnecessary, since the modules are either already loaded
or loaded shortly afterwards, so that we can get the required
information directly from the module handles. And actually, doing
`ImageLoad()` as well as `LoadLibrary()` leaves a tiny room for a race
condition, because both functions will lookup the module in the search
path, so there is no *guarantee* that both are dealing with the same
module. Dropping the `ImageLoad()` calls also has the advantage to no
longer face the issue reported in bug #79557. A very minor additional
advantage is that we no longer have to link against Imagehlp.dll.
Furthermore, there is no need to check for CRT compatibility multiple
times, so we can simplify the signature of `php_win32_crt_compatible`,
and at the same time clean up main.c a bit.
These changes require to change the signature of the exported
`php_win32_image_compatible` and `php_win32_crt_compatible` functions,
which now expect a `HMODULE` and nothing, respectively, instead of the
module name.
Some extension may need to retrieve the `gdImagePtr` from an `GdImage`
object; thus, we export the respective function. To not being forced
to include gd.h in php_gd.h, we use the opaque `struct gdImageStruct *`
as return type.
We also rename php_gd2.dll to php_gd.dll, since there's not really much
point in giving the DLL a version number, since there is no php_gd.dll
for years (if there ever has been). Renaming, on the other hand,
matches the name on other systems (gd.so), and allows to actually use
`ADD_EXTENSION_DEP()`.
Formerly, this had to be enabled by passing the configuration flag
`--enable-crt-debug`; now it can be enabled by setting the environment
variable `PHP_WIN32_DEBUG_HEAP`. The advantage is that it is no longer
necessary to do separate builds, at the cost of a very minor
performance penalty during process startup.
Building with `/W3` shows an awful lot of warnings on Windows, so it's
really hard to spot the more important ones. Since it is not possible
to override the hard-coded `/W3`, we drop it altogether, so MSVC uses
the default `/W1`. Users are encouraged to increase the warning level
via the environment variable `CFLAGS` before doing configure.
We also enable `/WX` (treat warnings as errors) for AppVeyor CI, using
`/W1` for now, since otherwise the build would fail.
