We need to look for the right file. To avoid total confusion, we also
rename the variables; however, the right solution would have been to
drop the version suffixes, since they don't help (major + minor maybe,
but not major only).
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.
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.
The `zend_system_id` is a (true global) system ID that fingerprints a process state. When extensions add engine hooks during MINIT/startup, entropy is added the system ID for each hook. This allows extensions to identify that changes have been made to the engine since the last PHP process restart.
Closes GH-5871
It does not make sense to make assumptions about `PHP_CONFIG_FILE_PATH`
during build time, since that value is never used during run time on
Windows. Since there is no `--with-config-file-path` on Windows
either, we define `PHP_CONFIG_FILE_PATH` as `""`.
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.
We have to actually determine the proper `SIZEOF_OFF_T`.
Interestingly, it is `4` on Windows x64.
We also have to prevent the redefinition in pg_config.h. The clean
solution would likely be to not include pg_config.h at all, but that's
out of scope for BC reasons for now.
php_mergesort() isn't being used for anything, and hasn't been for
a long time. Even if we wanted to use a stable sort, this isn't
the implementation we'd use...
Prefer '%define api.value.type' to '#define YYSTYPE', so that Bison
know the type.
Use '%code requires' to declare what is needed to define the api.value.type
(that code is output in the generated header before the generated
definition of YYSTYPE).
Prefer '%define api.prefix' inside the grammar file to '-p' outside,
as anyway the functions defined in the file actually use this prefix.
Prefer `%param` to both `%parse-param` and `%lex-param`.
Closes GH-5138
In the buildconf and configure batch files, Windows' cscript utility was being
run without the /e:jscript flag. This works on systems that have not had the
default .js file association changed, but if .js has been re-associated to
(say) an IDE, the batch files fail with the error message:
Input Error: There is no script engine for file extension ".js".
ASan instrumentation does not support the MSVC debug runtime, but still
it does not make sense to enable optimizations for such builds, since
they are not meant for production usage anyway, and although memory
corruption issues are still found in optimized builds, the generated
diagnostics are close to being useless, and apparently sometimes even
outright wrong. Therefore, we disable all optimizations for ASan
instrumented builds.
We also introduce and use `ZEND_WIN32_NEVER_INLINE` for ASan enabled
builds to avoid inlining of functions, so we get even better
diagnostics.
In the php-src repository, the test runner is named run-tests.php, but
when it is copied to the tests packs, it is renamed to run-test.php.
This renaming does not make sense, and is actually somewhat confusing.
Although changing the name back to run-tests.php constitutes a BC
break, we think the benefit of having a single name outweights the
disadvantages in the long run.
Currently mail related tests are split for *nix and Windows (if there
are even Windows versions). The basic difference is that the *nix
variants set the INI directive sendmail_path to just write the email to
disk, while the Windows tests use ext/imap. The latter tests are way
more verbose, and such duplicated tests are generally a pain point.
Furthermore, the Windows tests are much slower, and could not be run
without ext/imap being available.
We therefore introduce a small fakemail application, which basically
works like `tee <path> >/dev/null`, and which will be shipped with the
Windows tests packs. fakemail.exe would also need to be added to the
PHP binary SDK, so these tests could be run during developments.
To cater to the remaining differences, we also introduce support for
`{MAIL:<path>}` placeholders in the INI sections to run-tests.php. How
to use this can be seen in mail_basic.phpt, which is currently the only
modified test case, because these tests are yet supposed to fail on
Windows, due to the missing fakemail.exe in the PHP SDK.
