go to bug id or search bugs for
New/Additional Comment:
Description:
------------
Currently you can build PHP with Linux, Cygwin and Visual Studio. However
Mingw-w64 [1] is currently not supported. It would be invoked using:
./configure --host x86_64-w64-mingw32
or similar. You can tell for sure that is it not currently supported by looking
at "u_char". Mingw-w64 does not define this, same as Visual Studio. PHP accounts
for this with "win32/php_stdint.h" [2]:
typedef unsigned __int8 u_char;
However this same file cannot be used with Mingw-w64 [3]:
#error "Use this header only with Microsoft Visual C++ compilers!"
[1]
[2]
[3]
Add a Patch
Add a Pull Request
Hi @svnpenn
I think the main reason for this not being supported is that no one on the development team have ever done a build like that or there have been any past requests for it.
If its only u_char thats the issue, then perhaps the define can be moved to php.h (in php-src/main), where a lot of cross OS compatibility macros and types also are defined.
@kalle
it is not just u_char, several issues - but that is one
After some closer looking, "u_char" is actually defined by Mingw-w64
"_bsd_types.h" [1]:
typedef unsigned char u_char;
which is in turn included by "winsock2.h" [2]:
#include <_bsd_types.h>
we know this to be true because PHP is already doing it [3]:
#include <winsock2.h> /* Includes definition for u_char */
So we can bypass this particular error by including "winsock2.h" in the approriate place. However as said before this is not the only issue preventing Mingw-w64 build. Here is another example:
ext/date/php_date.c:2615:66: error: unknown type name ‘suseconds_t’
this is caused by not defining "PHP_WIN32" [4]. However, even if you define it, it still fails:
win32/time.h:20:8: error: redefinition of ‘struct timezone’
So in this case either "win32/time.h" need to be modified to support both Visual Studio and Mingw-w64, or perhaps a "mingw/time.h" needs to be introduced. Again, this is only one problem currently with trying a Mingw-w64 build.
[1]
[2]
[3]
[4]
Hi, thanks for the information.
I don't think defining or altering the macros/header files is a viable thing to make support for MingW, however I tried to make a patch based on your comment but I do not have any environment to be able to even test it, I put up a gist here if (tho it was done against master, it should apply for lower branches):
(Please change back the status of this report after testing)
Thanks!
@kalle that looks good so far but again those are only 2 issues. So far I have come across similar issues with the below additional files. Probably most files that assume "WIN32 == Visual Studio" are going to need some attention. Note I am working on a patch myself, but it is a slow process so maybe someone will be faster at it than me.
TSRM/TSRM.h
TSRM/tsrm_config_common.h
ext/fileinfo/libmagic/compress.c
ext/phar/func_interceptors.c
ext/phar/stream.c
ext/standard/basic_functions.c
ext/standard/crypt_freesec.c
ext/standard/dns.c
ext/standard/file.c
ext/standard/ftp_fopen_wrapper.c
ext/standard/http_fopen_wrapper.c
ext/standard/streamsfuncs.c
main/php_compat.h
main/php_network.h
main/php_syslog.h
added comment
Hi
I loaded up my linux dev and installed mingw32 from apt-get, however using the ./configure you provided in the report, the configure fails, however if I also pass along --disable-all it doesn't fail. Any chance you can help me by letting me know what packages to install to get this build going? I naturally have everything going to make a regular ./configure build of PHP (autoconf, gcc, libxml, etc) + Wine
My Linux dev is using Elementary which seems to be some Ubuntu flavor or at least thats where it gets its packages from \o/
Sure, here is what I am using currently. This might change once I actually get "make" to complete:
./configure --disable-dom --disable-libxml --disable-opcache \
--disable-posix --disable-simplexml --disable-xml --disable-xmlreader \
--disable-xmlwriter --without-iconv --without-pear --host x86_64-w64-mingw32
FYI I am putting my progress here:
Thank you for the update, I made similar progress as you yesterday, tho I did a little different approach by checking for __MINGW32__ :)
FYI I added a tag, so you can see a patch of the current changes at any of these links:
-
-
-
@kalle I made a pull request:
it does not close this issue, but it is a start
Related To: Bug #43658