My configure looks like

configure --with-openssl

It's not interesting...

Thanks for the report. You need to --enable-cli to run the packaging script. In further - which deps do you use, and which SDK?

Thanks.

Hello.

Yes, of course I tried differ keys which I need, looks like --enable-cli, --enable-embed etc. I'm using latest deps-7.1-vc14-x86.7z deps and tried deps-master-vc14-x86.7z too.

P. S. And yes, my SDK is the latest too from GitHub. Using VC++ 2015 for build.

Ah, and ext/zip enabled, too? Which exact configure line, please be more precise.

And latest from github, 2.0.0? Just to be sure. Whereby officially only the stable one is supported.

Another point yet to check also env and path, fe that there's nothing like Cygwin or anything else preceeding the path with SDK tools. And otherwise, probably would require you to debug the actual nmakefile part.

Thanks.

Hmm, ext/zip is not required. Still, need some kind of reproducer :/ Debugging the makefile were helpful, too.

Thanks.

I've simply reupload my sources from master branch, so now it have 7.2.0-dev version, and now it's seems working. I'm so sorry for that) But I think there's bugs in compiling, because I've do nothing with it, only compile it with VC. But now I've many "LNK2001 unresolved external symbol" errors, so I'm trying to build it in Visual C++ 15.0 for this version... But I'm sure, that I've compiled this version yet, but now I have this errors but I've compiled the same souces.
Thanks anyway)

Making some own tests, I'll write you till it completed.

Hello!

I've made more than 10 builds with differ configs and have established, that this problem is actual only with OpenSSL compile and PHP >= 7.1 Besides this problem it's appeared, that final php.exe is unworkable and throw a error

"Serial number 385 was not found in the library .dll C:\PHP\sdk\phpdev\vc14\x86\php-7.2.0-dev\Release\php7.dll"

when it starts (standart Win32 window, not compiler, it have no errors).

Some kind of thoughts (just a theory) - that I've based my PHP src at C:\PHP\sdk, not C:\php-sdk, it seems that you'll try to check its path in OpenSSL sources, I think it's necessary to make changes at it, so than it could see a relative paths, because I have no problems with other modules with my own path.

Thanks.

Thanks for the further checking. Unfortunately you still didn't tell which exact binary tools you use. But otherwise, if the error message you've posted is onlyto see with OpenSSL enabled, there are two things. First, seems you compile ext/openssl statically, which should not be done if using the official deps. Then - seems there are some other OpenSSL DLLs on your path, that differ from what the deps package provides.

Thanks.

Wow! Seems it working now when I try to build it shared. I've no need to get DLLs separated when I compile it statically, so I didn't do it. But I think you should make it forcibly shared like opcache, gd, etc, or, if it impossible for some reasons, at least make an announcement in manual that it must be only compiled shared, because I've spent more than three days to find a reason in my broken sources as I think, because I believed that it can't be so fail bug with OpenSSL which is idle in fact.

Ah, and yes, seems that I forgot to tell you which binary I've use (but I'm sure that I've done it) - it's the latest one from GitHub, I've dovnloaded it time after time I've build my own PHP so far.

Yeah, you told latest binary tools from github, but it's actually versioned, so there can be certain difference. That's why i asked to be precise and there's more on report process here https://bugs.php.net/how-to-report.php ;) Be aware about the compatibility notes https://wiki.php.net/internals/windows/stepbystepbuild_sdk_2, likely it'll work as expected but please use the stable tag, 2.0.0 currently.

ext/openssl is already shared by default, except an explicit option is given. Depending on what you need, simplest were to --enable-snapshot-build, except you'd need some highly customized build. Probably we indeed could disable static building of ext/openssl, need to evaluate the consequences. In general, custom builds should not be prohibited.

Thanks.

Hello!

Well, yes, I understand this, but I thought that binary tools must be actually with the PHP version, otherwise it'll birth more problems than solves it. And finally, it's recommends for download with GitHub at the latest version of manual, which you've gave to me. But okay, will try to use 2.0.0, no problems)

Well, I afraid it's not static by default (when not to put the "shared" value forcibly I mean). It was necessary for me only to use the --with-openssl=shared forcibly to compile it shared.

Thanks for advice with --enable-snapshot-build, I read about it. But can I ask you about its value more deeply? What is phrase "turns on everything it can" means? Is it means that its builds it with all extensions embed by default?

Thanks a lot!

P. S. If we talk about options - what is --enable-one-shot key really means too, especially "not so hot for edit-and-rebuild hacking" phrase? I don't want to create a new bug report with the template "<key> working but ignoring", but I tried it to use it for the more quickly builds because I need to test my own extensions etc, but it seems that it's not working on latest PHP versions, because on 7.1.3 it build tooks less than 20 secs, but at the 7.2.0-dev it take more than 5 minutes with the same configs.

On the wiki, it's about latest <b>stable</b>. Anyway, --with-extname can now be forced shared by default in 7.0, see f7b8322b144122baddaf365c37dca3b8e547725e and please check.

The --enable-one-shot option appears to be dead. Seems it were implemented long ago for some older VS compilers, today it has absolutely no implementation. For that, --with-mp is enabled by default with the snapshot build, otherwise you have to pass it manually, see configure --help for details. I'm going to remove --enable-one-shot in master, as it has already no effect since long.

For custom extensions, I'd recommend the dev SDK and in addition maybe also https://github.com/FriendsOfPHP/pickle . But even the dev alone is a good choice for a faster build.

Thanks.

Thanks a lot for your answer and specially for pickle, because now I'm porting some of my ancient extensions to the PHP7 and I'm compelled to compile the PHP ten times a day, so I hope it'll help (is it?).