Feature #3705
openBuild PHP extension of Saxon for Windows
Added by O'Neil Delpratt almost 7 years ago. Updated almost 6 years ago.
0%
Description
Reported here: https://stackoverflow.com/questions/49010431/build-php-extension-of-saxon-for-windows
Bug issue created to track the progress of building a PHP extension for Saxon/C 1.1.0 on windows.
Updated by O'Neil Delpratt almost 7 years ago
- Status changed from New to In Progress
confiog.w32 file content:
ARG_ENABLE("saxon", "enable saxon extension", no);
if ($PHP_SAXON != "no") {
EXTENSION("saxon", "php7_saxon.cpp SaxonProcessor.cpp XQueryProcessor.cpp XsltProcessor.cpp XPathProcessor.cpp SchemaValidator.cpp XdmValue.cpp XdmItem.cpp XdmNode.cpp XdmAtomicValue.cpp SaxonCGlue.c SaxonCProcessor.c SaxonCXPath.c", true);
}
On Windows:
For PHP 7.0.27 the following guide might be more helpful: https://wiki.php.net/internals/windows/stepbystepbuild
I tried building with PHP 7.2 using the following guide: https://wiki.php.net/internals/windows/stepbystepbuild_sdk_2
This guide led me to use the github page: https://github.com/Microsoft/php-sdk-binary-tools which got me further in the build process. Getting some build errors in the C++ code which needs investigating.
Updated by Drew Borell over 6 years ago
Not a c/c++ expert here -- PHP developer. I think the config mentioned above is still not correct but I am not the authority on this topic. My corrections you can find below.
Dev Environment
Windows 10 x64
Visual Studio 2017
JDK 10.0.1
PHP 7.2.6 source
PHP Build Tools
I was able to compile but I have not tested it.
ARG_ENABLE("saxon", "enable saxon extension","no");
if(PHP_SAXON == "no") {
EXTENSION("saxon", "php7_saxon.cpp SaxonProcessor.cpp XQueryProcessor.cpp XsltProcessor.cpp XPathProcessor.cpp SchemaValidator.cpp XdmValue.cpp XdmItem.cpp XdmNode.cpp XdmAtomicValue.cpp SaxonCGlue.c SaxonCProcessor.c SaxonCXPath.c")
PHP_INSTALL_HEADERS("", "ext/xml");
}
My steps to compile:
make sure jdk is installed and you have rebooted so the PATH environment variable is updated. Let me repeat specifically I said JDK, the Java Development Kit. NOT JRE, the Java Runtime Environment.
Configure JAVA_HOME environment variable if it is not automatically configured to point to the JDK installation. Java Native Interface ( jni.h ) in the include directory seemed to be required to compile.
Install visual studio 2017 and reboot.
Download binary tools as zip ( or git from cli if you git )
[[https://github.com/Microsoft/php-sdk-binary-tools]]
extract zip
Download PHP source
[[https://windows.php.net/downloads/releases/php-7.2.6-src.zip]]
extract zip
Open vs 2017 x64 command prompt. Do not use the x86 x64 command prompt because PHP does not support this.
cd \
cls
mkdir php-sdk
( copy extracted php binary tools files from inner directory into this directory )
cd php-sdk
phpsdk-vc15-x64.bat
phpsdk_buildtree
( will automatically CD to you architecture directory )
( copy the PHP source here e.g. php-7.2.6-src )
cd php-7.2.6-src
copy the libsaxonhec.dll into the ext directory
create a folder called saxon in the ext directory
copy the config.w32 ( and correct as above ), and all other files into that directory. Do not use --disable-all --enable-cli in the configure command.
buildconf
configure --enable-saxon
nmake
I have not tested the above but have compiled successfully with expected warnings etc. Some other notes regarding the HE-1.1.0 installer on the download page:
-
There is no sln\vbproj in the windows binaries installed via the HE version from the download page.
-
There is no DLL either, and the readme.md indicated both the dll and the sln\vbproj exist. These are in the previous release however.
-
The config.w32 is not updated with the information in the previous post.
Updated by Drew Borell over 6 years ago
After Further review, while it did compile in the cli successfully it did not actually generate any dll for saxon. I changed both config.w32 "no" values to yes, changed the configure to
configure -disable-cgi --enable-saxon=shared
cannot get it to compile again. last error is
ext\saxon\php7_saxon.cpp(890): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
Seems to have trouble after converting a 32-bit integer to a 64-bit integer. Maybe someone else can offer a suggestion to get this on track?
Updated by O'Neil Delpratt over 6 years ago
Hi,
Thanks for having a go at pushing the Saxon/C PHP Windows forward. I will look at your suggestions at my end and report back on this thread.
Updated by O'Neil Delpratt over 6 years ago
Update on PHP windows build:
I have managed to get the the same stage as reported in comment #3. There are a few compile errors which appear only under the windows platform which I am going through.
Updated by Drew Borell over 6 years ago
I made some progress on this but still do not have a compiled DLL. Note that I did this in x86 this time, but you should always keep your architecture in line with the version you are building for
When using the configure command the screen had scrolled so fast I didnt really catch all the output until I went back. There are a half dozen or so errors finding dependencies. The one of most concern to me was the error finding mscoree.h:
Checking for mt.exe ... C:\Program Files (x86)\Windows Kits\10\bin\10.0.17134.0\x86
Checking for mscoree.h ... <not found>
[[https://www.microsoft.com/en-us/download/details.aspx?id=49978]]
There were other errors are dependency errors which I resolved downloading the zip files for the target architecture here:
[[https://windows.php.net/downloads/php-sdk/deps/vc15/]]
and extracting those zip files into the deps directory here:
C:\php-sdk\phpdev\vc15\x86
( replace x86 with x64 if you are building on x64 )
In my opinion this command should work,
configure --disable-cgi --enable-saxon --with-all-shared
However when I tried that command I saw link errors to php_SHA256.
This is an alternate configure command which still exits with 0x2 but its a step in the right direction. I dont think the type casting is what causes the compiler to exit prematurely.
configure --disable-all --enable-cli --enable-bcmath=shared --enable-calendar=shared --enable-ctype=shared --enable-filter=shared --enable-hash=shared --enable-json=shared --enable-opcache=shared --enable-phar=shared --enable-session=shared --enable-tokenizer=shared --enable-xmlreader=shared --enable-xmlwriter=shared --enable-zip=shared --enable-zlib=shared --enable-saxon=shared
All of these DLL did build up to opcache.dll before it terminates. Perhaps I should focus on the PHP_SHA256 link errors instead of the second configure command. The reason I tried the second command is that I thought it might try to build the dependencies in that order with saxon.dll last so all the deps were compiled by the time it reached saxon.
Updated by O'Neil Delpratt over 6 years ago
Thanks for your update.
Most of the errors I am getting are to do with the struct sxnc_environment which is defined in SaxonCGlue.h
For example:
..\..\..\..\..\saxon-php-extension\saxon\SaxonCXPath.c(276): error C2440: 'function': cannot convert from 'sxnc_environment' to 'sxnc_environment *(__cdecl *)()'
I am not seeing the same problem on the C/C++ compiler on linux.
Updated by Drew Borell over 6 years ago
Same problem I am seeing, but I found two other issues. In the SaxonCGlue.c there is a hard coded path that is wrong:
//TODO When windows version of Saxon/C is done we will have to fixup this
strncpy(dllname, "C:\\Program Files\\Saxonica\\SaxonHEC1.0.1", 42);
strncpy(resources_dir, "C:\\Program Files\\Saxonica\\SaxonHEC1.0.1", 42);
They obviouosly should be 1.1.0 and there are other references similar to above that may not be updated as well.
Despite this comment says it is not used under windows, the env_len variable is mispelled and should be corrected, or declared.
enc_len = 8; //not used under windows
Keep in mind, I havent used C since college many years ago, but do you think this may be an issue with compiling on Windows 10? I can try to compile on a Win7 machine later. The reason I ask is because one of my first errors references the environment.
error C2040: '__p__environ': 'sxnc_environment **()' differs in levels of indirection from 'char ***(void)'
If you recall I was seeing errors that errno.h could not be found. I resolved that issue by installing Universal CRT. Here is an interesting page I came across on the Microsoft website:
[[https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps]]
If I am not mistaken, this is telling me a bunch of runtime functions are not available in UWP/UCRT. One of those happens to be _environ, the first error I see when compiling. From there I could see everything that relies on the environment going in a tailspin which is exactly what is happening. Maybe this is only an issue with VS2017 on Windows 10?
What are your thoughts?
Updated by Community Admin over 6 years ago
Drew Borell wrote:
Same problem I am seeing, but I found two other issues. In the SaxonCGlue.c there is a hard coded path that is wrong:
[...]
They obviouosly should be 1.1.0 and there are other references similar to above that may not be updated as well.
Yes I have corrected that one locally, but I will raise a separate bug issue against it.
Despite this comment says it is not used under windows, the env_len variable is mispelled and should be corrected, or declared.
[...]
Yes there is a bug issue against that one. See: #3816
Keep in mind, I havent used C since college many years ago, but do you think this may be an issue with compiling on Windows 10? I can try to compile on a Win7 machine later. The reason I ask is because one of my first errors references the environment.
[...]
If you recall I was seeing errors that errno.h could not be found. I resolved that issue by installing Universal CRT. Here is an interesting page I came across on the Microsoft website:
[[https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps]]
If I am not mistaken, this is telling me a bunch of runtime functions are not available in UWP/UCRT. One of those happens to be _environ, the first error I see when compiling. From there I could see everything that relies on the environment going in a tailspin which is exactly what is happening. Maybe this is only an issue with VS2017 on Windows 10?
What are your thoughts?
Interesting. I will have to look into this some more.
I am working on making the sxnc_environment as pointers in the function calls.
Updated by O'Neil Delpratt almost 6 years ago
- Description updated (diff)
comment #9 has been fixed and will be issued in the maintenance release 1.1.2 for Windows shortly
Please register to edit this issue