Coder Social home page Coder Social logo

microsoft / php-sdk-binary-tools Goto Github PK

View Code? Open in Web Editor NEW
269.0 28.0 78.0 113.35 MB

Tool kit for building PHP under Windows

License: BSD 2-Clause "Simplified" License

PHP 16.19% C 19.96% C++ 10.06% XSLT 7.64% Batchfile 1.62% M4 41.83% Awk 2.52% Smarty 0.17%
php-sdk c php windows build cpp

php-sdk-binary-tools's Introduction

PHP SDK

PHP SDK is a tool kit for Windows PHP builds.

License

The PHP SDK itself and the SDK own tools and code are licensed under the BSD 2-Clause license. With the usage of the other tools, you accept the respective licenses.

Overview

The toolset consists on a mix of the hand written scripts, selected MSYS2 parts and standalone programs. It supports any workflows, be it a custom, local or a CI build whatsoever.

The PHP SDK 2.2+ is compatible with PHP 7.2 and above.

The PHP SDK 2.1 is required to build PHP 7.1 or 7.0.

The legacy binary tools SDK is available from the legacy branch and is suitable to build PHP 5.

Requirements

  • A 64-bit build host
  • Windows 7 or later
  • Visual C++ 2017 or Visual C++ 2019 must be installed prior SDK usage. Required components
    • C++ dev
    • Windows SDK
    • .NET dev
  • if Cygwin, MingW or any other cross solution is installed, please read notes in the pitfalls section

Tools

SDK

  • starter scripts, named phpsdk-<crt>-<arch>.bat
  • phpsdk_buildtree - initialize the development filesystem structure
  • phpsdk_deps - handle dependency libraries
  • phpsdk_dllmap - create a JSON listing of DLLs contained in zip files
  • phpsdk_pgo - run PGO training
  • phpsdk_version - show SDK version
  • task.exe - wrapper to hide the given command line

Other tools

  • bison 3.3.2, re2c 1.1.1, lemon
  • awk, gawk, sed, grep, jq
  • diff, diff3, patch
  • md5sum, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum
  • 7za, zip, unzip, unzipsfx
  • wget, pwgen

Optional, not included

These are not included with the PHP SDK, but might be useful. While Visual C++ is the only required, the others might enable some additional functionality. Care yourself about making them available on your system, if relevant.

  • Git - useful for PHP source management
  • Cppcheck - used for static analysis
  • clang - useful for experimental builds and for static analysis
  • ICC - useful for experimental builds
  • ConEmu - console emulator with tabs and more

Usage

The PHP SDK should be unzipped into the shortest possible path, preferably somewhere near the drive root.

Usually, the first step to start the PHP SDK is by invoking one of the suitable starter scripts. This automatically puts the console on the correct environment relevant for the desired PHP build configuration.

It is not required to hold the source in the PHP SDK directory. It could be useful, for example, to simplify the SDK updates.

Basic usage example

  • git clone https://github.com/Microsoft/php-sdk-binary-tools.git c:\php-sdk
  • cd c:\php-sdk
  • git checkout php-sdk-2.1.9 or later
  • invoke phpsdk-vc15-x64.bat
  • phpsdk_buildtree phpmaster
  • git clone https://github.com/php/php-src.git && cd php-src, or fetch a zipball
  • phpsdk_deps --update --branch master, use phpsdk_deps --update --branch X.Y for a non master branch
  • do the build, eg. buildconf && configure --enable-cli && nmake

More extensive documentation can be found on the wiki.

The old way

  • git clone https://github.com/Microsoft/php-sdk-binary-tools.git c:\php-sdk
  • follow the instructions on the PHP wiki page

Customizing

Custom environment setup

A script called phpsdk-local.bat has to be put into the PHP SDK root. If present, it will be automatically picked up by the starter script. A template for such a script is included with the PHP SDK. This allows to automatically meet any required preparations, that are not foreseen by the standard PHP SDK startup. Be careful while creating your own phpsdk-local. It's your responsibility to ensure the regular PHP SDK startup isn't broken after phpsdk-local.bat was injected into the startup sequence.

Console emulator integration

The starter scripts can be also easy integrated with the consoles other than standard cmd.exe. For the reference, here's an example ConEmu task

C:\php-sdk\phpsdk-vc15-x64.bat -cur_console:d:C:\php-sdk\php72\vc15\x64\php-src

Unattended builds

An elementary functionality to run unattended builds is included. See an example on how to setup a simple unattended build task in the doc directory.

Be aware, that starter scripts always start a new shell. Scripts intended to run as a task need to be passed with -t argument to a starter script.

Upgrading

  • backup phpsdk-local.bat
  • backup the source trees and any other custom files in the PHP SDK root, if any present
  • move the PHP SDK folder into trash
  • download, unpack and the new PHP SDK version under the same path
  • move the custom files back in their respective places

If the PHP SDK is kept as a git checkout, merely what is needed instead is to git fetch and to checkout an updated git tag.

Extending

The SDK tools are based on the KISS principle and should be kept so. Basic tools are implemented as simple batch script. The minimalistic PHP is available for internal SDK purposes. It can be used, if more complexity is required. A suitable PHP binary is bound with the PHP SDK. If you have an idea for some useful tool or workflow, please open a ticket or PR, so it can be discussed, implemented and added to the SDK. By contributing an implementation, you should also accept the SDK license.

PGO

As of the version 2.1.0, the SDK includes a tool for the PGO optimization. Several training cases are included by default, which are based on the real life opensource applications. The PGO optimization can give an overall speedup up to 30%. The work on adding more training scenarios for the widely used opensource apps is ongoing. If you have a training scenario to share, please create a PR to this repo. Any new training cases are thoroughly validated through the extensive performance tests.

Preparing PGO training environment

  • the pgo folder in the SDK root dir contains templates and scenarios for PGO training
  • adjust and execute doc/phpsdk_pgo_prep_elevated.bat.example to open ports required for PHP SDK training servers
  • run phpsdk_pgo --init. Note that composer requires huge amounts of memory, so it may be necessary to set the environment variable COMPOSER_MEMORY_LIMIT=-1. The PGO initialization may not succeed in x86 enviroments.

Creating PGO build

  • compile PHP configured using --enable-pgi
  • run phpsdk_pgo --train
  • run nmake clean-pgo
  • rebuild PHP --with-pgo

Adding custom PGO training scenario

A custom scenario can be used to produce a custom PHP binary dedicated to an arbitrary application.

The existing training cases can be found in pgo/cases. Assumed the case would be named myapp, the general steps to setup were

  • create the case directory under pgo/cases/myapp
  • create pgo/cases/myapp/phpsdk_pgo.json with the necessary definitions
  • create pgo/cases/myapp/nginx.partial.conf with a partial NGINX template
  • create pgo/cases/myapp/TrainingCaseHandler.php with a class as defined in the interface

After a training case is implemented and put under pgo/cases, the work environment needs to be reinitialized. The tool puts all the training data and necessary applications under pgo/work. Rename or remove that directory and rerun phpsdk_pgo --init.

To skip a training case, add a file named inactive into the case folder.

Debugging PHP

This part covers debugging possibilities for the builds produced by the native VS compilers. For the cross compiled builds produced with toolsets other than VC++, please check the documentation for the corresponding toolsets. In any case, general principles on debugging native programs apply.

Either a debug build of PHP or enabled debug symbols are required to be able to debug PHP. A debug build is usually more suitable for the development process and can be produced by adding --enable-debug to the configure options. A release build with debug symbols can be produced by adding --enable-debug-pack. These options are mutually exclusive.

Debugging with Visual Studio

  • Configure with either --enable-debug or --enable-debug-pack.
  • A debug build might bring better experience for dev, but sometimes you want to debug a release build.
  • nmake run ARGS=yourscript.php DEBUGGER=1, that will open a Visual Studio window.
  • Any additional runtime options for PHP or the script executed go to ARGS, too.
  • Select Debug -> New Breakpoint -> Function Breakpoint and add a function where the debugger should break.
  • Click Start.

Adding a breakpoint before starting debugging might be not necessary, if a crash is debugged. When such a script runs under the debugger, the debugger will stop at the crashing point. In that case, a breakpoint can be added around the crashed code directly.

Debugging test suite with Visual Studio

The Microsoft Child Process Debugging Power Tool plugin for Visual Studio is required. After installing it, following these steps

  • nmake test TESTS=ext/myext/tests/sometest.phpt DEBUGGER=1
  • Select Debug -> Other Debug Targets -> Child Process Debugging Settings and enable child process debugging.
  • If necessary, add a breakpoint and start debugging as described in the previous section.

Debugging with WinDbg

PHP can also be debugged with the tools from the WinDbg package. There is currently no way implemented in the Makefile to start the WinDbg integrated, so it needs to de done manually. Either a debug build or a release build with debug symbols is still required, as described previously.

Support

  • Join #winphp-dev on Freenode to discuss any ideas or questions
  • File an issue on GitHub

Pitfalls

  • SDK or PHP sources put into paths including spaces might cause issue.
  • SDK or PHP sources put into too long paths, will cause an issue.
  • If Cygwin, MSYS2 or MinGW flavors are exposed in global PATH, it might cause issues. If it's unavoidable, ensure SDK preceeds it on the PATH.
  • When fetching the binary SDK from git, git core.autocrlf configuration directive set to false is recommended.
  • Tools, based on MSYS2, only accept paths with forward slashes.
  • Both Visual C++ toolset and the Windows SDK components have to be installed for the PHP SDK to work properly.
  • The VC++ toolset is still required, even if another compiler, fe. clang, is intended to be used.
  • task.exe is not a console application, some systems might not propagate exit code except the batch is explicitly run from cmd /c, etc.
  • 7za should be preferred over unzip and zip for compatibility reasons.
  • If you experience some strange crashes on MSYS2 tools, try the phpsdk_rebase_msys2 tool. MSYS2 tools might be have unstable on ASLR enabled systems.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

php-sdk-binary-tools's People

Contributors

alexandergabriel avatar cmb69 avatar dktapps avatar gemorroj avatar jan-e avatar jerry-shaw avatar johnstevenson avatar theodorejb avatar weltling avatar yaowenqiang avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

php-sdk-binary-tools's Issues

Persistent Connection with mysqli : define MYSQLI_NO_CHANGE_USER_ON_PCONNECT for Windows build

On page https://dev.mysql.com/doc/apis-php/en/apis-php-mysqlnd.persist.html , it introduced how to disable change user for persistent connection as follows:
shell# CFLAGS="-DMYSQLI_NO_CHANGE_USER_ON_PCONNECT" ./configure --with-mysql=/usr/local/mysql/ --with-mysqli=/usr/local/mysql/bin/mysql_config --with-pdo-mysql=/usr/local/mysql/bin/mysql_config --enable-debug && make clean && make -j6
or
shell# export CFLAGS="-DMYSQLI_NO_CHANGE_USER_ON_PCONNECT"
shell# configure --whatever-option
shell# make clean
shell# make
However this only works on Linux build, may I ask when I want to build php mysqli using PHP SAK tools for windows following steps on this git post, what should I do to define MYSQLI_NO_CHANGE_USER_ON_PCONNECT to disable change user?

Error in phpsdkpgo

phpsdk_pgo --init give following error:
Uncaught SDK\Exception: OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 10054 in D:\php-sdk\lib\php\libsdk\SDK\FileOps.php:152

how to build

s:\VCS\Git\php-sdk-binary-tools>phpsdk-vc15-x64.bat
[vcvarsall.bat] Environment initialized for: 'x64'

PHP SDK 2.1.8-dev

OS architecture:    64-bit
Build architecture: 64-bit
Visual C++:         15
PHP-SDK path:       s:\VCS\Git\php-sdk-binary-tools

s:\VCS\Git\php-sdk-binary-tools
$ cd phpmaster\vc15\x64\php-src

s:\VCS\Git\php-sdk-binary-tools\phpmaster\vc15\x64\php-src
$ buildconf.bat
Rebuilding configure.js
Now run 'configure --help'

s:\VCS\Git\php-sdk-binary-tools\phpmaster\vc15\x64\php-src
$ configure --enable-cli --disable-all
PHP Version: 7.4.0-dev

Saving configure options to config.nice.bat
Checking for cl.exe ...  <in default path>
  Detected compiler MSVC15 (Visual C++ 2017)
  Detected 64-bit compiler
Checking for link.exe ...  <in default path>
Checking for nmake.exe ...  <in default path>
Checking for lib.exe ...  <in default path>
Checking for bison.exe ...  <in default path>
Checking for sed.exe ...  <in default path>
Checking for re2c.exe ...  <in default path>
  Detected re2c version 1.0.3
Checking for zip.exe ...  <in default path>
Checking for lemon.exe ...  <in default path>
Checking for 7za.exe ...  <in default path>
Checking for mc.exe ...  <not found>
Checking for mt.exe ...  <not found>
Enabling multi process build

Build dir: S:\VCS\Git\php-sdk-binary-tools\phpmaster\vc15\x64\php-src\x64\Release_TS
PHP Core:  php7ts.dll and php7ts.lib

Checking for wspiapi.h ...  <not found>
Checking for wspiapi.h ...  <not found>
Enabling SAPI sapi\cli
Checking for library edit_a.lib;edit.lib ... <in deps path> \lib\edit_a.lib
Checking for editline/readline.h ...  <in deps path> \include
Enabling extension ext\date
Enabling extension ext\pcre
Enabling extension ext\reflection
Enabling extension ext\spl
Checking for timelib_config.h ...  ext/date/lib
Enabling extension ext\standard

Creating build dirs...
Generating files...
Generating Makefile
Generating main/internal_functions.c
        [content unchanged; skipping]
Generating main/config.w32.h
Generating phpize
Done.



Enabled extensions:
-----------------------
| Extension  | Mode   |
-----------------------
| date       | static |
| pcre       | static |
| reflection | static |
| spl        | static |
| standard   | static |
-----------------------


Enabled SAPI:
-------------
| Sapi Name |
-------------
| cli       |
-------------


------------------------------------------------
|                   |                          |
------------------------------------------------
| Build type        | Release                  |
| Thread Safety     | Yes                      |
| Compiler          | MSVC15 (Visual C++ 2017) |
| Architecture      | x64                      |
| Optimization      | PGO disabled             |
| Native intrinsics | SSE2                     |
| Static analyzer   | disabled                 |
------------------------------------------------


Type 'nmake' to build PHP

s:\VCS\Git\php-sdk-binary-tools\phpmaster\vc15\x64\php-src
$ nmake

Служебная программа обслуживания программ Microsoft (R), версия 14.14.26433.0
(C) Корпорация Майкрософт (Microsoft Corporation).  Все права защищены.

        "" -h win32\ -r S:\VCS\Git\php-sdk-binary-tools\phpmaster\vc15\x64\php-src\x64\Release_TS\ -x S:\VCS\Git\php-sdk-binary-tools\phpmaster\vc15\x64\php-src\x64\Release_TS\ win32\build\wsyslog.mc
"-h" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
NMAKE : fatal error U1077: " : возвращенный код "0x1"
Stop.

see https://github.com/php/php-src/blob/master/win32/build/Makefile#L117
Apparently, I have not set the variable MC.
Can you help?

Unable to compile due to compiler version mismatch (iconv?)

mismatch between 'P1' version '20161212' and 'P2' version '20150812'

Seems one of the dependencies is compiled using VC14

Last thing i get before the error is:

libiconv_a.lib(iconv1.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
fatal error C1900: Il mismatch between 'P1' version '20161212' and 'P2' version '20150812'
LINK : fatal error LNK1257: code generation failed
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\link.exe"' : return code '0x4e9'
Stop.

If I do --without-libxml --without-iconv everything works correctly. (Why on earth is iconv a dependency to libxml?)

This happens both with 7.2 branch and master.

WshShell.Exec: Access is denied.

hi

I have a problem in installing

on this command :
$ configure

error :
c:\php-sdk\phpmaster\vc15\x64\php-src\configure.js(164, 2) WshShell.Exec: Access is denied.

And with this command :
$ namek

NMAKE : fatal error U1064: MAKEFILE not found and no target specified
Stop.

Link-time Code Generation with MSVC 15.7 issue

Hi,
Since MSVC 15.7 update, I can't anymore build with Link-time Code Generation
Ex.

  • With /LTCG for LDFLAGS and /GL for ARFLAGS & CFLAGS:
    • fatal error C1047: Le fichier objet ou le fichier bibliothèque 'C:\php72-sdk\phpmaster\vc15\x86\deps\lib\libiconv_a.lib' a été créé à l'aide d'un compilateur antérieur à celui d'autres objets ; régénérez les objets et bibliothèques obsolètes
  • Without /LTCG for LDFLAGS and /GL for ARFLAGS & CFLAGS:
    • libiconv_a.lib(iconv1.obj) : .netmodule ou module MSIL compilé avec /GL trouvé ; redémarrage de l'édition de liens avec /LTCG ; ajoutez /LTCG à la ligne de commande de l'édition de liens pour améliorer les performances de l'Éditeur de liens
    • And same message for freetype_a.lib

For details about MSVC version, here are

Do you think it would be possible to update libiconv and freetype dependencies build either with:

  • MSVC 15.7 (cl 19.14)
  • without /GL CFLAGS

Don't hesitate to come back to me if needed.

Could not found vc15 folder.

I am getting error "could not found vc15 folder".
How to resolve it ?
I installed visual studio 2019 community edition.

Argument 1 passed to SDK\Cache::__construct() must be of the type string

I've been trying to update deps this last 30 minutes with various variations of:

phpsdk_deps --update --branch master

Nothing seems to work though - for some reason nothing can be detected - current CRT, architecture or even PHP branch.

My current project structure looks like so:

C:\php-sdk - this git repo on tag php-sdk-2.1.3
C:\php-sdk\phpmaster\
C:\php-sdk\phpmaster\vc15\x64\deps - dependencies (from some earlier install?)
C:\php-sdk\phpmaster\vc15\x64\php-src - git repo of https://github.com/php/php-src on branch PHP-7.2.4

Visual Studio 2017 Community v15.6.5


What I did originally:

  1. I had this system set up already (with instructions from the readme file)
  2. I opened cmd prompt in C:\php-sdk
  3. I ran phpsdk-vc15-x64.bat
  4. I ran phpsdk_buildtree phpmaster (just in case) - it simply complained that dirs already exist
  5. I ran phpsdk_deps --update --branch master and got the error mentioned in the title

Can't build PHP 7.1.11 on Windows 10 x64

I try to build PHP 7.1.11 on Windows 10 x64 according to new [building manual]
(https://wiki.php.net/internals/windows/stepbystepbuild_sdk_2)
Have installed Visual Studio Community 2015 (full installation, all the components).

When running phpsdk-vc14-x64.bat error message occuring

ERROR: The system was unable to find the specified registry key or value.
Windows SDK not found.

It happen because bin\phpsdk_setshell.bat try to check registry for HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.1

But name of this key in my system's registry is v8.1A

Also, there is no Include directory in SDK's installation path.

May be problem is in Community VS edition? Should I use Professional, or Enterprise one?

Take external openssl

The command phpsdk_deps --update --branch master downloads several dependencies of PHP7.2. One of them is OpenSSL. During normal compilation of PHP7.2, it would use the OpenSSL version taken from the phpsdk_deps command.

I have compiled OpenSSL on my own and I want to use this version as a dependency. Is it somehow possible, to use another OpenSSL version and not the one taken from the phpsdk_deps command?

Cannot build 7.2.5 with master

I getting this errors trying to build php-7.2.5 branch

 Creating library D:\php-sdk\php-7.2-nts-release\vc15\x86\php-src\Release\php_zip.lib and object D:\php-sdk\php-7.2-nts-release\vc15\x86\php-src\Release\php_zip.exp
php_zip.obj : error LNK2019: unresolved external symbol __imp__zip_add referenced in function _get_module
php_zip.obj : error LNK2019: unresolved external symbol __imp__zip_add_dir referenced in function _get_module
php_zip.obj : error LNK2019: unresolved external symbol __imp__zip_get_file_comment referenced in function _get_module
php_zip.obj : error LNK2019: unresolved external symbol __imp__zip_get_num_files referenced in function _zif_zip_open
php_zip.obj : error LNK2019: unresolved external symbol __imp__zip_rename referenced in function _get_module

Heur.AdvML.B in task.exe?

Hello.

After git clone my antivirus (Symantec Endpoint Protection) is reporting task.exe as being a heuristic virus (Heur.AdvML.B) on Windows 10.

After using the binary tools, the antivirus also removed some .dll from a php extension I was recompiling (.dll previous compiled for php 7.1 and now trying to compile for 7.2 with new toolkit).
I not sure why Symantec now think my extension .dll is also a virus (it removed permanently without recover option, so I couldn't check the .dll's content to compare with a previous SHA512 I made of the file).

So I think that a should inform about this problem with task.exe. Hope is only me that are having this problem and not that task.exe in repository is contaminated.

'-h' is not recognized as an internal or external command

buildconf -> ok
configure --disable-all --enable-cli ->ok
nmake -> error.

It seems in quotes it should be some command, but it is empty now :(

D:\Projects\Php\phpdev\vc15\x64
$ nmake

Microsoft (R) Program Maintenance Utility Version 14.10.25019.0
Copyright (C) Microsoft Corporation. All rights reserved.

Recreating build dirs
type ext\pcre\php_pcre.def > D:\Projects\Php\phpdev\vc15\x64\x64\Release_TS\php7ts.dll.def
"" -h win32\ -r D:\Projects\Php\phpdev\vc15\x64\x64\Release_TS\ -x D:\Projects\Php\phpdev\vc15\x64\x64\Release_TS\ win32\build\wsyslog.mc
'-h' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: '"' : return code '0x1'
Stop.

Uncaught TypeError: Argument 1 passed to SDK\Cache::__construct() must be of the type string, null given

Fatal error: Uncaught TypeError: Argument 1 passed to SDK\Cache::__construct() must be of the type string, null given, called in C:\projects\php-sdk\lib\php\libsdk\SDK\Config.php on line 128 and defined in C:\projects\php-sdk\lib\php\libsdk\SDK\Cache.php:14
Stack trace:
#0 C:\projects\php-sdk\lib\php\libsdk\SDK\Config.php(128): SDK\Cache->__construct(NULL)
#1 C:\projects\php-sdk\lib\php\libsdk\SDK\Config.php(165): SDK\Config::getKnownBranches()
#2 C:\projects\php-sdk\bin\phpsdk_deps.php(99): SDK\Config::setCurrentBranchName('7.2')
#3 {main}
  thrown in C:\projects\php-sdk\lib\php\libsdk\SDK\Cache.php on line 14

Using the following:

C:\projects\php-sdk\bin\phpsdk_deps.bat --update --branch 7.0 --arch x64 --dir C:\projects\php-src\deps

from the drive root (v2.0.9)

Active CRT 'vc15' differs from the branch CRT 'vc14'

When I try to get the deps for PHP 7.0.30 I get the message:

Fatal error: Uncaught SDK\Exception: Active CRT 'vc15' differs from the branch CRT 'vc14'. in C:\php-sdk\bin\phpsdk_deps.php:131
Stack trace:
#0 {main}
  thrown in C:\php-sdk\bin\phpsdk_deps.php on line 131

This windows is running inside a VMware and is a fresh install.

My specs are:

OS: Windowx 10 Pro x64
Visual Studio 2017 Community

$ phpsdk-vc15-x86.bat
[vcvarsall.bat] Environment initialized for: 'x86'

PHP SDK 2.1.5

OS architecture:    64-bit
Build architecture: 32-bit
Visual C++:         15
PHP-SDK path:       C:\php-sdk

It does not support gdb debug.

I'm very sorry to bother you.
I was used PHP-SDK compiled DEBUG PHP. But it does not support GDB debug.

nmake clean 
buildconf
configure --disable-all  --enable-cli --with-all-shared  --enable-test --disable-zts --enable-debug
nmake

image
image

How can I do to debug PHP_SDK compiled PHP use GDB?
thanks.

vswhere fails to locate VS Community 2017

I have installed Microsoft Visual Studio Community 2017 (Version 15.1 (26403.3) Release). Running either phpsdk-vc15-x86.bat or phpsdk-vc15-x64.bat yields:

Das System kann den angegebenen Pfad nicht finden.

I've tracked that down to the respective vswhere call. Running the following directly:

vswhere -nologo -version 15 -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath -format text

prints nothing, so that PHP_SDK_VC_DIR is empty.

However, running

vswhere -nologo -version 15 -property installationPath -format text

yields C:\Program Files (x86)\Microsoft Visual Studio\2017\Community which exists, but there is no VC folder in it.

vswhere not found

I followed the Basic Usage steps for tag php-sdk-2.1.5, but failed on step 4 with the following error:

c:\php-sdk>phpsdk-vc15-x64.bat
'c:\php-sdk\bin\\vswhere' is not recognized as an internal or external command,
operable program or batch file.
'c:\php-sdk\bin\\vswhere' is not recognized as an internal or external command,
operable program or batch file.
'c:\php-sdk\bin\\vswhere' is not recognized as an internal or external command,
operable program or batch file.
Could not determine 'vc15' directory

I've got Microsoft Visual C++ 2017 version 15.7.3.

I had to add vswhere to PATH manually (by adding %ProgramFiles(x86)%\Microsoft Visual Studio\Installer entry), but I still get the same error above.

Edit: Replacing %~dp0\vswhere with vswhere in bin\phpsdk_setshell.bat seems to make it work. I still had to add vswhere manually to PATH as described previously.

Buildtree deps folder

Following step by step guide.
As an idea, I think "phpsdk_buildtree phpdev" should not add empty "deps" folder.
As later git cloning does not work as folder is not empty.
Anyway, later "phpsdk_deps -u" create it.

Add tee(1) to new_binary_tools

It would be great to have tee(1) to be guaranteed to be available, so the mail() related PHPTs could finally be unified for Linux and Windows. The current situation where one has to employ ext/imap to test mail() on Windows is very unfortunate.

Not building any more because of updated libiconv dependency

Hi,

I can't build php any more using current master branch dependencies.
Today, libiconv got updated at https://windows.php.net/downloads/php-sdk/deps/vc15/x64/:
6/24/2018 10:42 AM 3503092 libiconv-1.15-2-vc15-x64.zip

Last night, building was still possible but now i get an error.
If i use deps vom branch 7.2, it still works.
I use VS 2017 Community Edition on Windows 10 x64 and try to build PHP x64 TS from current master branch.

Here's output of nmake snap:

C:\dev\work\php-sdk\phpmaster\vc15\x64\php-src
$ nmake snap

Microsoft (R) Program Maintenance Utility Version 14.13.26129.0
Copyright (C) Microsoft Corporation. All rights reserved.

Recreating build dirs

Microsoft (R) Program Maintenance Utility Version 14.13.26129.0
Copyright (C) Microsoft Corporation. All rights reserved.

Recreating build dirs
libiconv_a.lib(iconv1.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
fatal error C1007: unrecognized flag '-Ot' in 'p2'
LINK : fatal error LNK1257: code generation failed
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\bin\HostX64\x64\link.exe"' : return code '0x4e9'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.

grafik

phpsdk-vc15-x64.bat does not detach after calling

I am writing a script, which should compile PHP 7.2 on a Windows system in an automatic way. So, whenever there is a new version for PHP 7.2, I do not have to do all this stuff by hand. For this, I am using batch. But after calling phpsdk-vc15-x64.bat, I get this output and my script does not go on:

[vcvarsall.bat] Environment initialized for: 'x64'

PHP SDK 2.1.5-dev

OS architecture: 64-bit
Build architecture: 64-bit
Visual C++: 15
PHP-SDK path: D:\some\path\to\php7.2\build\deps

D:\some\path\to\php7.2\build
$

In my batch file, there is this written:

:: ...
set "PHP_SDK_X64=%PHP_DEPS%\phpsdk-vc15-x64.bat"
:: ...
call "%PHP_SDK_X64%"

It does not matter, what I am writing after my call of phpsdk-vc15-x64.bat, my script stop at the dollar sign $.

Can you give me a way how to handle this problem? This seems to be a bug for me.

Compiling php 64 bits PGO enabled

How to make builds with pgo enabled for x64? I've compiled php7.3.1 x86 TS with success with pgo enabled, but for x64 builds do'nt have luck!
Have 3 errors: libssl1_1-x64.dll, libcrypto1_1-x64.dll and image below:
screenshot_24

How to proceed?

PGO CLI Training

I can´t see a relevant implementation of cli trainings.
class Training endsup with the default exception in run() -> case "cli".
Issnt it implemented yet?

Where to update phpsdk_deps?

I have problems to understand, where to run this command phpsdk_deps --update --branch master (in the paragraph Basic usage example).

When I understand the paragraph correct, then I should be in the directory php-src and then run this command ..\path\to\phpsdk_deps --update --branch master. Is this correct? Or should I be outside of the php-src directory?

Php and extension debugging under windows

Hi!

Im compiling and building an extension for php. It works but there are some scenarios (php scripts) where it crashes with no information logged. I've loved this repo for easily giving the ability to build. I was also able to include debugging symbols for php and the extension. I haven't been able to find any material on how to debug php and extensions on Windows under visual studio or visual studio code.

Would you have any insight or resources you could share?

checking sdk-binary-tools versions

It would be nice if compilation of PHP and/or extensions was equipped with some kind of versions check. Configure system should detect unsupported versions of binaries.

I had a problem with compilation because I had another instance of bison and others tools on my computer. Some more details on the newslist http://news.php.net/php.pecl.dev/11459.

The updated plan for https://windows.php.net/downloads/php-sdk/deps-7.1-vc14-x64.7z

Hi all,

I have a question to ask. The archives (5.6, 7.0) are updated in 2018.
But only the 7.1 archive is not updated. What is the reason for this?

Ref. https://windows.php.net/downloads/php-sdk/
3/30/2018 3:49 AM 27645065 deps-5.6-vc11-x64.7z
3/30/2018 3:49 AM 25876397 deps-5.6-vc11-x86.7z
2/27/2018 10:35 PM 39857610 deps-7.0-vc14-x64.7z
2/27/2018 10:35 PM 37222501 deps-7.0-vc14-x86.7z
4/27/2017 8:18 PM 40213850 deps-7.1-vc14-x64.7z
4/27/2017 8:17 PM 37479597 deps-7.1-vc14-x86.7z

Thank all.

Supporting multiple toolsets for a single VS installation

Hi @weltling,
I try to manage VC15 & VS16 php build with VS 2019 preview.

according to microsoft/vswhere#158 VS 2019 preview is only seen by vswhere as a prerelease...
Also note that vswhere -nologo -version "[15,16)" -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath -format text -prerelease didn't return anything where vswhere -nologo -version 16 -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath -format text -prerelease & vswhere -nologo -version 15 -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath -format text -prerelease both correctly return the VS installation path ^^

Also, having the two version of the compiler tools (14.16 & 14.22) one the same VS 2019 preview instance, here is the way I've managed it with phpsdk_setshell.bat

diff --git "a/bin/phpsdk_setshell.bat" "b/bin/phpsdk_setshell.bat"
index 3d12e3b..248c872 100644
--- "a/bin/phpsdk_setshell.bat"
+++ "b/bin/phpsdk_setshell.bat"
@@ -84,8 +84,7 @@ if 15 gtr %PHP_SDK_VS_NUM% (
 	rem build the version range, e.g. "[15,16)"
 	set /a PHP_SDK_VS_RANGE=PHP_SDK_VS_NUM + 1
 	set PHP_SDK_VS_RANGE="[%PHP_SDK_VS_NUM%,!PHP_SDK_VS_RANGE%!)"
-
-	for /f "tokens=1* delims=: " %%a in ('%~dp0\vswhere -nologo -version !PHP_SDK_VS_RANGE! -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath -format text') do (
+	for /f "tokens=1* delims=: " %%a in ('%~dp0\vswhere -nologo -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath -format text -prerelease') do (
 		set PHP_SDK_VC_DIR=%%b\VC
 	)
 	if not exist "!PHP_SDK_VC_DIR!" (
@@ -144,15 +143,15 @@ if 15 gtr %PHP_SDK_VS_NUM% (
 
 if /i "%PHP_SDK_ARCH%"=="x64" (
 	if 15 gtr %PHP_SDK_VS_NUM% (
-		set PHP_SDK_VS_SHELL_CMD="!PHP_SDK_VC_DIR!\vcvarsall.bat" amd64
+		set PHP_SDK_VS_SHELL_CMD="!PHP_SDK_VC_DIR!\vcvarsall.bat" amd64 -vcvars_ver=%vcvars_ver%
 	) else (
-		set PHP_SDK_VS_SHELL_CMD="!PHP_SDK_VC_DIR!\Auxiliary\Build\vcvarsall.bat" amd64
+		set PHP_SDK_VS_SHELL_CMD="!PHP_SDK_VC_DIR!\Auxiliary\Build\vcvarsall.bat" amd64 -vcvars_ver=%vcvars_ver%
 	)
 ) else (
 	if 15 gtr %PHP_SDK_VS_NUM% (
-		set PHP_SDK_VS_SHELL_CMD="!PHP_SDK_VC_DIR!\vcvarsall.bat" x86
+		set PHP_SDK_VS_SHELL_CMD="!PHP_SDK_VC_DIR!\vcvarsall.bat" x86 -vcvars_ver=%vcvars_ver%
 	) else (
-		set PHP_SDK_VS_SHELL_CMD="!PHP_SDK_VC_DIR!\Auxiliary\Build\vcvarsall.bat" x86
+		set PHP_SDK_VS_SHELL_CMD="!PHP_SDK_VC_DIR!\Auxiliary\Build\vcvarsall.bat" x86 -vcvars_ver=%vcvars_ver%
 	)
 )

where vcvars_ver is

  • 14.22 for phpsdk-vs16-xXXbat
  • 14.16 for phpsdk-vc15-xXXbat

For sure it may not be the good way to do it but this draft works ^^

no genera librerias dll

no se genera ninguna libreria dll cuando se ejecuta el comando --with-library_name=shared (ejemplo ibm_db2 y pdo_ibm )

Trying to Create My own Extension

i m trying to make my own extension but when i execute "nmake" it says enable to found "Myextesion.c " is there away to make the compiler generate the "Myextesion.c " for me or i have to created myself
ps: i m trying to avoid re-implementing the modules on c

PGO INIT Error

screenshot_3

phpsdk_pgo --init has error show on image above! after compiling, init the script for pgo building environment, but this error appear! what's happening?

Unable to compile PHP 7.2 using Visual Studio 2017

I followed the steps outlined in Basic usage example, trying to compile PHP. I have Visual Studio 2017 (v15.0) installed, and I've used Developer Prompt to run the starter batch (tested with both phpsdk-vc15-x86 and phpsdk-vc15-x64).

When I ran configure I saw PHP Version: 7.3.0-dev, which is not what I want.
Therefore, I downloaded php-7.2.0-beta1-src.zip today and simply tried phpsdk_deps -u.

The SDK was downloaded into deps, but when trying the last step buildconf && configure --enable-cli && nmake, I have the same issue as described in http://news.php.net/php.pecl.dev/11459.

An excerpt of the output of nmake:

Recreating build dirs
	"cl.exe" /D _USRDLL /D PHP7DLLTS_EXPORTS /D PHP_EXPORTS /D LIBZEND_EXPORTS /D TSRM_EXPORTS /D SAPI_EXPORTS /D WINVER=0x0601 /D COMPILE_DL_GD /D COMPILE_DL_OPCACHE -Iext/bcmath/libbcmath/src /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1  /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /DHAVE_MSCOREE_H=1  /Iext/date/lib /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /DHAVE_TIMELIB_CONFIG_H=1 /wd4244 /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /I "ext/hash/sha3/generic32lc" /DHAVE_KECCAKHASH_H=1 /DKeccakP200_excluded /DKeccakP400_excluded /DKeccakP800_excluded /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include" /DHAVE_ICONV_H=1 /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /D PHP_ICONV_EXPORTS /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -Iext/pcre/pcrelib -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /D HAVE_CONFIG_H /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include" /DHAVE_EDITLINE_READLINE_H=1 /D HAVE_LIBEDIT /D HAVE_RL_COMPLETION_MATCHES /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /I "ext/date/lib" /DHAVE_TIMELIB_CONFIG_H=1 /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1  /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include" /DHAVE_ZIP_H=1 /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\lib\libzip\include" /DHAVE_ZIPCONF_H=1 /D _WIN32 /D ZLIB_EXPORTS /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include\libxml2" /DHAVE_LIBXML_PARSER_H=1 /DHAVE_LIBXML_TREE_H=1 /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /D LIBXML_STATIC /D LIBXML_STATIC_FOR_DLL /D HAVE_WIN32_THREADS /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include\libxml2" /DHAVE_LIBXML_PARSER_H=1 /D LIBXML_STATIC /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include\libxml2" /DHAVE_LIBXML_TREE_H=1 /D LIBXML_STATIC /D PHP_SIMPLEXML_EXPORTS /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include\libxml2" /DHAVE_LIBXML_PARSER_H=1 /DHAVE_LIBXML_TREE_H=1 /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /D LIBXML_STATIC /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include\libxml2" /DHAVE_LIBXML_PARSER_H=1 /D LIBXML_STATIC /I "ext/date/lib" /DHAVE_TIMELIB_CONFIG_H=1 /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include\libxml2" /DHAVE_LIBXML_PARSER_H=1 /DHAVE_LIBXML_TREE_H=1 /D LIBXML_STATIC /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include\libxml2" /DHAVE_LIBXML_XMLWRITER_H=1 /D LIBXML_STATIC /nologo /I . /I main /I Zend /I TSRM /I ext /D _WINDOWS /D WINDOWS=1 /D ZEND_WIN32=1 /D PHP_WIN32=1 /D WIN32 /D _MBCS /W3 /D _USE_MATH_DEFINES /FD /wd4996 /D_USE_32BIT_TIME_T=1 /guard:cf /Zc:inline /MP /LD /MD /W3 /Ox /D NDebug /D NDEBUG /D ZEND_WIN32_FORCE_INLINE /GF /D ZEND_DEBUG=0 /I "C:\php-sdk\bin\phpmaster\vc15\x86\deps\include" /D FD_SETSIZE=256 /FoC:\php-sdk\bin\phpmaster\vc15\x86\php-7.2.0-beta1-src\Release\Zend\ /FpC:\php-sdk\bin\phpmaster\vc15\x86\php-7.2.0-beta1-src\Release\Zend\ /FRC:\php-sdk\bin\phpmaster\vc15\x86\php-7.2.0-beta1-src\Release\Zend\ /FdC:\php-sdk\bin\phpmaster\vc15\x86\php-7.2.0-beta1-src\Release\Zend\ /D ZEND_ENABLE_STATIC_TSRMLS_CACHE=1 /c Zend\zend.c Zend\zend_API.c Zend\zend_alloc.c Zend\zend_ast.c Zend\zend_builtin_functions.c Zend\zend_closures.c Zend\zend_compile.c Zend\zend_constants.c Zend\zend_default_classes.c Zend\zend_exceptions.c Zend\zend_execute.c Zend\zend_execute_API.c Zend\zend_extensions.c Zend\zend_float.c Zend\zend_gc.c Zend\zend_generators.c Zend\zend_hash.c Zend\zend_highlight.c Zend\zend_inheritance.c Zend\zend_ini.c Zend\zend_ini_parser.c Zend\zend_ini_scanner.c Zend\zend_interfaces.c Zend\zend_iterators.c Zend\zend_language_parser.c Zend\zend_language_scanner.c Zend\zend_list.c Zend\zend_llist.c Zend\zend_multibyte.c Zend\zend_object_handlers.c Zend\zend_objects.c Zend\zend_objects_API.c Zend\zend_opcode.c Zend\zend_operators.c Zend\zend_ptr_stack.c Zend\zend_smart_str.c Zend\zend_sort.c Zend\zend_sprintf.c Zend\zend_stack.c Zend\zend_stream.c Zend\zend_string.c Zend\zend_strtod.c Zend\zend_ts_hash.c Zend\zend_variables.c Zend\zend_virtual_cwd.c Zend\zend_vm_opcodes.c 
zend.c
zend_API.c
zend_alloc.c
zend_ast.c
zend_builtin_functions.c
zend_closures.c
zend_compile.c
zend_constants.c
Zend\zend_compile.c(23): fatal error C1083: Cannot open include file: 'zend_language_parser.h': No such file or directory
zend_default_classes.c
Zend\zend_ast.c(25): fatal error C1083: Cannot open include file: 'zend_language_parser.h': No such file or directory
zend_exceptions.c
zend_execute.c
zend_execute_API.c
zend_extensions.c
...

I also did the followings:
where bison.exe
this returns c:\php-sdk\msys2\usr\bin\bison.exe

but when I ran bison.exe against Zend\zend_language_parser.y I got the following error
c:\php-sdk\phpmaster\vc15\x86\php-src\Zend\zend_language_parser.y: fatal error: invalid @ in skeleton: @

I also have Visual Studio 2015 installed in the same PC, and I never had problems with php 7.0.* or php 7.1.* using Visual Studio native prompts

Forgot to mention that I did try version 2.0.0, 2.0.7 and the latest (2.0.8-dev) in this step:
git checkout php-sdk-2.0.0 or later

Deps for PHP 7.2 unavailable

The package deps-7.2-vc15-x64.7z and deps-7.2-vc15-x86.7z is not available on http://windows.php.net/downloads/php-sdk/.

I need this for build automatically PHP's extensions for Windows with appveyor.

Could not determine 'vc15' directory

Hi,

when I'm invoking the command phpsdk-starter.bat -c vc15 -a x64 I get the error:
Could not determine 'vc15' directory

I've done the steps as described in the section Basic usage example.

I'm using a Windows Terminal-Server and VS 2017 on x64 system.

Regards
Martin

Libtidy 5.6.0 issue

Hi,
Since libtidy 5.6.0 update (2018-10-17) there’s an error compiling --with-tidy
fatal error LNK1120: 171 external symbols unresolved
We must compile tidy ext shared to work --with-tidy=shared
Seems to be an error linked with php-src:
/ext/tidy/php_tidy.def included in /ext/tidy/config.w32 on:

if (!PHP_TIDY_SHARED) {
	ADD_DEF_FILE("ext\\tidy\\php_tidy.def");
}

But maybe it’ll be better to keep libtidy 5.4.0 until php-src are updated

Failed to unpack, error code '19'

d:\php-sdk\phpmaster\vc14\x64\php-src-php-7.0.14
$ phpsdk_deps --update --branch master

Configuration: master-vc14-x64-staging

Processing package apache-2.4.23-vc14-x64.zip
Processing package c-client-2007f-vc14-x64.zip
Processing package dirent-20080629-vc14-x64.zip
Processing package fbclient-2.5-nocrt-x64.zip
Processing package freetype-2.7.0-vc14-x64.zip
Processing package glib-2.49.4-vc14-x64.zip
Processing package ICU-57.1-vc14-x64.zip

Fatal error: Uncaught SDK\Exception: Failed to unpack, error code '19' in D:\php-sdk\lib\php\libsdk\SDK\Dependency\Package.php:54
Stack trace:
#0 D:\php-sdk\lib\php\libsdk\SDK\Dependency\Manager.php(68): SDK\Dependency\Package->unpack('D:\\php-sdk\\.tmp...')
#1 D:\php-sdk\bin\phpsdk_deps.php(185): SDK\Dependency\Manager->performUpdate(NULL)
#2 {main}
  thrown in D:\php-sdk\lib\php\libsdk\SDK\Dependency\Package.php on line 54

Empty user agent causes fetcher to fail

The fetcher returns the following data from the server:

20/feb/2018: Hi! We seem to be receiving high volume requests coming from empty user agents. While this shouldn't be an issue, this unfortunately resulted in bandwidth issues on this server causing all downloads to be unavailable. We've therefore decided to temporarily block empty user agents until we upgraded our server bandwidth.

03/mar/2018: We've upgraded the server bandwidth. This is however still not sufficient to handle all empty user agent connections. Please update the user agent in your scripts accordingly or contact us so we can discuss it.

Thank you for your understanding.

The fix is to add the following in FileOps::download():

curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 (Windows NT) Curl');

Bundle PHP 7.4

PHP 7.4 is out and it is the latest stable, so this version should be also bundled.

PHP 7.4 build failure with default dependencies

PHP 7.4 unbundles liboniguruma, which currently is only available with the staging dependencies, but by default the stable dependencies are used. Therefore, builds which try to enable mbregex will fail. This is no problem with the rmtools, since these always use staging dependencies, but users who are doing their own builds with the plain SDK are likely to stumble over this.

I suggest to either use staging dependencies for PHP 7.4 temporarily (until first beta), or to push libonig to stable soon.

phpsdk_deps update exception on Windows x64 (empty user agent)

TLDR: phpsdk_deps --update ... step throws exceptions on Win 8.1 x64

I use Windows 8.1 pro x64. Installed Visual-Studio-Community-2017 (v15.7.3) and Git (2.17) from git-scm.com. I also get the same symptom on Windows 7.1 pro. Both are physical machines.

PHP is not installed. I want to build PHP-7.2.6 because I want to compile a non-core extension (build DLL) for php-7.2.6.

I have a problem with the instructions shown in the 'Basic usage example' section of the readme, specifically with the step:

"phpsdk_deps --update --branch master, use phpsdk_deps --update --branch X.Y for a non master branch"

That phpsdk_deps step fails with this message:

$ phpsdk_deps --update --branch master
 
 Fatal error: Uncaught SDK\Exception: Failed to fetch supported branches in C:\php-sdk\lib\php\libsdk\SDK\Config.php:154
 Stack trace:
 #0 C:\php-sdk\lib\php\libsdk\SDK\Config.php(164): SDK\Config::getKnownBranches()
 #1 C:\php-sdk\bin\phpsdk_deps.php(105): SDK\Config::setCurrentBranchName('master')
 #2 {main}
   thrown in C:\php-sdk\lib\php\libsdk\SDK\Config.php on line 154

Before I got the above problem, I ran these commands, successfully:

git clone https://github.com/Microsoft/php-sdk-binary-tools.git c:\php-sdk

cd C:\php-sdk

git checkout php-sdk-2.0.12

phpsdk-vc15-x64.bat

phpsdk_buildtree phpmaster

git clone -b PHP-7.2.6 https://github.com/php/php-src.git

In Config.php line 130 $tmp = $fetcher->getByUri(self::$depsBaseUri . "/series/");
is returning in $tmp a message complaining about empty user agent. An earlier issue mentioned this. I'm using what I think is the latest sdk. phpsdk_version reports 2.0.12

Bad build ID when compiling standalone extension on 7.2

Hello,

I have a build process to compile an extension directly, without requiring to compile the full PHP src at the same time. This works well from 5.4 to 7.1, but fails with 7.2: the DLL is correctly created, but when I try to load it with a php 7.2 downloaded from windows.php.net, it fails with the following message. I'd need a hint to move forward... Would anyone know what is wrong?
Thanks in advance for any help you could provide.

**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.5.1
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall] Environment initialized for: 'x86'
PHP Warning:  PHP Startup: blackfire: Unable to initialize module
Module compiled with build ID=API20170718,TS,19.12.25830.2
PHP    compiled with build ID=API20170718,TS,VC15

What's the problem? unrecognized %destructor

d:\php-sdk\phpdev\vc14\x64\php-src-php-7.0.14>nmake

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

        bison.exe --output=Zend/zend_ini_parser.c -v -d -p ini_ Zend/zend_ini_parser.y
zend/zend_ini_parser.y:295: unrecognized: %destructor
zend/zend_ini_parser.y:295:    Skipping to next %
NMAKE : fatal error U1077: 'd:\php-sdk\bin\\..\bin\bison.exe' : return code '0x1'
Stop.

How to re-compile only specific extensions?

@weltling

Hi, this might be a bit off-topic, but figured i'd ask in case the answer was quick.

I'd like to (re)compile php_sqlite3.dll and/or php_pdo_sqlite.dll with some of the amalgamation [1] extensions enabled. Specifically FTS5 [2], but I assume the process would be the same for others, too. What would be the steps involved in building just those php extensions (with the needed sqlite extensions) without having to recompile all of php in the process?

let's assume latest stable 7.* release and new_binary_tools branch

thanks if you can help :)

[1] https://www.sqlite.org/amalgamation.html
[2] https://www.sqlite.org/fts5.html

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.