-
Notifications
You must be signed in to change notification settings - Fork 200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building v8 on windows #287
Comments
cc'ing our man for Windows packaging @Jan-E :-) TBH I'm really undecided what to think of both our PHP V8 extensions wrt. Windows. I'm not a Windows user at all and to me it feels like demand for V8Js on Windows is really little. So so far I was really happy that @Jan-E started to care :) ... after some painful use/debugging on Windows (on AWS instances) before myself. I'd really appreciate if we'd have up-to-date packages, maybe regularly built on appveyor. Yet I don't have the time to care for the infrastructure myself. I used to have a Windows package builder on the Jenkins instance (with on-demand build slaves on AWS), yet this is broken for a long time |
I'm also not a Windows user, probably like you, but I stick to macOS. I just remembered that you have some windows support, but I see that there is pretty old v8. Also, having proper libv8 builds for windows will make possible building dlls on pecl, which itself should be quite nice for windows users (if any). But let's hear from Jan-E is a nuget good for our goals or not (I have only a brief idea what is it). |
@Jan-E Recently we decided to introduce a sandboxed-script engine into our product by using the V8JS extension. As always when integrating new PHP modules I went to this thread. But unfortunatly the Windows builds of the V8 library are broken since you moved from V8 4.9 to 5.4+.
There is a segmentation fault and the whole PHP Engine terminates like this:
I think it has something to do with the NativeTypes store that can not be found in V8. Can you please checkout the problem? Right now we use the V8Js extention from your build php-7.0.12-nts-Win32-VC14-x64 as this uses the old V8 engine 4.9.385.29. Thanks in advance for your checks! |
Ouch. Nasty bug. Try |
Hi @Jan-E! Another thing I recognised was that passing 64-bit integers back-and-forth between PHP and JavaScript does not work (see test 1). When converting the 64-bit integers to strings the passing (see test 2): // test 1 (Exchange 64-bit ints natively)
$addInt = function ($a, $b) {
return $a + $b;
};
$v8 = new V8Js('PHP');
$v8->add = $addInt;
$v8->p1 = 10;
$v8->p2 = pow(2,45);
$result1 = $v8->executeString('var res = PHP.p1+PHP.p2;"p1:"+PHP.p1+", p2:"+PHP.p2+", PHP.add(p1,p2)="+PHP.add(PHP.p1,PHP.p2)+", p1+p2="+res+" -> "+(new Date(res)).toISOString();');
// test 2 (Exchange 64-bit ints as STRING)
$addString = function ($a, $b) {
return (String)(intval($a) + intval($b));
};
$v8 = new V8Js('PHP');
$v8->add = $addString;
$v8->p1 = '10';
$v8->p2 = (String)pow(2,45);
$result2 = $v8->executeString('var res = parseInt(PHP.p1)+parseInt(PHP.p2);"p1:"+PHP.p1+", p2:"+PHP.p2+", PHP.add(p1,p2)="+PHP.add(PHP.p1,PHP.p2)+", p1+p2="+res+" -> "+(new Date(res)).toISOString();');
$result = array('native64' => $result1, 'string64' => $result2); Even with the V8 Build you attached // v8_version: "5.8.301.0"
// ext_version: "1.3.3"
result: {
native64: "p1:10, p2:0, PHP.add(p1,p2)=10, p1+p2=10 -> 1970-01-01T00:00:00.010Z",
string64: "p1:10, p2:35184372088832, PHP.add(p1,p2)=35184372088842, p1+p2=35184372088842 -> 3084-12-12T12:41:28.842Z"
} On Linux with @pinepain 's PPA V8 5.2 the // v8_version: "5.2.371"
// ext_version: "1.3.3",
result: {
native64: "p1:10, p2:35184372088832, PHP.add(p1,p2)=35184372088842, p1+p2=35184372088842 -> 3084-12-12T12:41:28.842Z",
string64: "p1:10, p2:35184372088832, PHP.add(p1,p2)=35184372088842, p1+p2=35184372088842 -> 3084-12-12T12:41:28.842Z"
} |
Good to hear it works now. With respect to the ints: it even goes wrong with some 32-bits ints. Everything >= pow(2,31) results in either a negative value or zero. Either V8 itself or the extension still treats Windows or PHP7 on Windows as 32-bits. This is not true anymore for PHP7 on 64-bits Windows: http://php.net/manual/en/language.types.integer.php I simplified your testscript a little bit to play around with different values:
Result (in PHP 7.1 nts x64):
|
This is how I built V8 5.8. TL;DR: these are the essential commands for x64.
Prerequisites:
My initial setup was a mixture of the Linux & Windows commands at https://www.chromium.org/developers/how-tos/install-depot-tools
Then I ran the following batch script, inside a 'VS2015 x64 Native Tools Command Prompt' (x64) or a 'VS2015 x86 Native Tools Command Prompt' (x86):
That is all. In the most condensed form I could describe it... |
From #287 (comment)
I spent a couple of hours to solve that. 'v8_use_snapshot=false' was the crux: it disables the inclusion of https://github.com/v8/v8/blob/master/src/snapshot/natives-external.cc |
I created a separate issue for the 32/64-bits integers: |
@Jan-E thanks for reply. What do you think about packaging v8 to nuget as state in a first comment here?
|
I would not mind if @pmed adds V8 5.8-lkgr to NuGet but I do not have the time for it. |
I feel you. Anyway, closing as I'm not using windows and have no plans to introduce it support in my own ext at this time. |
BTW: I tested the 64-bits integer script ( #292 ) with this x64 NuGet build: https://www.nuget.org/packages/v8-v140-x64/ The output was the same. So the NuGet build has the same issue. |
Another BTW: I always publish my builds at These builds are not yet updated with V8 5.8-lkgr, but the RC's are updated already: |
Fixed by #293 in x64-bits builds on https://www.apachelounge.com/viewtopic.php?t=6617
|
Hi @stesie! I found that it's not an easy task to build both v8js and php-v8 on windows, mostly because of lack of up to date v8 distribution. At this time I don't even build for windows as I don't even have windows machine, though, I think it might be interested for some users.
At this time I found pmed/v8-nuget repo which targets on building v8 for windows platform (see pacakges - https://www.nuget.org/profiles/pmed). I guess it might be interesting for you even in a state it is.
As my extension stick to the bleeding edge, I'm pretty interested to adapt that building script for some 5.8 or at least 5.6. Basically, even 5.6 (the stable branch) would be ok, as v8 changed their build system at 5.5, I guess. At this time I have already adapted build scripts for homebrew and ubuntu, which, with minor tweaks I'm working right now, could be used as a ground for v8-nuget upgrading.
So if you are interested, we may ask @pmed for assisance or offer him some assistance and get that windows packages.
The text was updated successfully, but these errors were encountered: