23 March 2012

Static build PHP 5.4.0 with MinGW

Experimental fully static build of PHP 5.4.0 with moderate bundled extensions compiled with MinGW. Though not supported, PHP turned out can be built with modern GCC under windows as long as we specify the correct  _WIN32_WINNT. Most features can be enabled too with exception dotnet module due to insufficient headers and libraries and also Zend inline optimization need to be disabled.

The CLI version has readline support in interactive mode (good for learning) similar to those linux build.

configure --enable-static --enable-embed=static --disable-fpm --disable-posix --disable-inline-optimization --enable-fd-setsize=256 --enable-maintainer-zts --disable-shared --with-readline --with-openssl --with-zlib --with-bz2 --enable-zip --with-libxml-dir --with-libexpat-dir --with-xsl --enable-wddx --enable-soap --with-xmlrpc --with-gd --with-jpeg-dir --with-png-dir --with-vpx-dir --enable-gd-native-ttf --enable-gd-jis-conv --with-freetype-dir --with-t1lib --enable-exif --enable-calendar --with-curl --with-curlwrappers --enable-ftp --with-libmbfl --with-onig --enable-mbstring --enable-sockets --enable-shmop --enable-bcmath --with-gmp --enable-intl --with-icu-dir --with-pspell --with-iconv-dir --with-gettext --with-mhash --with-mcrypt --with-tidy --with-ldap --with-imap --with-snmp --enable-mysqlnd --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-pgsql --with-pdo-pgsql --with-pdo-odbc=generic,/usr/local,odbc32 --with-pdo-dblib --with-db4 --enable-dba --with-custom-odbc CUSTOM_ODBC_LIBS=-lodbc32
Autotools configuration should not be used since it missing winsock awareness and can be replaced by supplied win32 config (used for MSVC). Being a static build means all extensions are loaded at startup therefor it's quite a dog for repetitive processing but convenient enough for interactive mode.

CGI: php-cgi.exe 8.45MB
CLI: php.exe 8.44MB

For more detailed info, use php-cgi -i > config.html

update: php-5.4.10 static binary (mingw patch and hints included)


  1. Thank for PHP CLI!
    Can you compile it without SNMP support so no MIB warnings will be given? Thanks in advance!

  2. I have smalller/basic version as part Tuma MinGW (addons 0.5d) you can extract it (under /opt/bin folder) using 7-zip without having installing it first.


  3. This comment has been removed by the author.

  4. could you please compile php with --enable-pcntl and --enable-posix ,then d11wtq / boris would run on windows.

    links :

    1. Hi 王思,
      while it's possible to use posix thread in mingw, it doesn't mean other posix features can be enabled.

  5. can we compile latest php 5.7-dev with mingw?

    1. I don't know... it's been a while but if I want to give it a shot I will go for stable releases 5.8.x

    2. I'm just visiting php.net and seeing only 5.5.x-dev series? are you sure there such 5.7.x-dev ?

    3. 5.7-dev is not official release. it's come from latest source and i do build with vs. With GCC? :(


  6. would you please tell us how to build php from source under mingw step by step?.

    1. Before that, first a proper autotools patch needed. Mine is just screwed up :D I wasn't familiar with those *.ac *.am files back then.

      Also more importantly How much interest the upstream developers have to maintain a mingw port?

    2. dunno others. for me so interesting. I try to compile wxWidgets and php under mingw. wxWidgets compile succesfully. but PHP? dunno where to start ;). mingw not supported except vs as far as i know

  7. Great work!

    I bumped into the problem of 64-bit int with the official x86_64 build for Windows. I tried several times to build PHP with MinGW under CygWin but all failed.
    So is it possible to build a x86_64 with 64-bit int supported version?

    1. What do you mean with 64bit int support? isn't it what supposed to be in 64bit build. Usually if 32bit compilable then the usual 64bit problems are intptr or inline ASM. I haven't try though.

  8. currently use msys2 just "./configure && make" success build, but static, dunno how to make a shared extension, always failed, can't load an extension at runtime.

    1. That's good news.
      As I remember there is a placeholder to load all static extensions, of course if your exe is big then youre OK.

      To be able to load "other" shared extension you need to compile it yourself and *link it* to your php.exe or php-cli.exe (make sure your exe already export symbols) and you can't exchange extension between exes. I've done it with xdebug, it worked fine.

  9. I notice the references to pcntl, posix and /usr/local prefix. I am confused if this is a true MinGW port or an MSYS port? They are two development systems. MSYS is actually based on Cygwin and only works with MinGW on the command-line level.

    1. Errrr.. can't you tell... of course it's mingw. You do understand that cygwin binaries will depends on cygwin.dll aren't you? I even have my own MSYS/MinGW toolchain (during making this static build) http://opensourcepack.blogspot.co.id/p/moluccas.html

    2. And you're wrong about MSYS/Cygwin/Mingw stuff. For terminology sake Mingw = native GCC + MSYS. but Mingw also the name of the Win32 API with GNUC compatibility. The native gcc compiler itself can be used with WHATEVER shell you have: Cygwin, Msys, plain cmd, cmake, etc.

  10. Cool, so if you are using MinGW why oh why are you using the /usr/local prefix for odbc instead of the correct /mingw one? Anyway as for MSYS, yes you can use the shell but NO you cannot link against it - which is why its important to distinguish between the two. Frankly I think MSYS was a big mistake they should have just build a minimal posix library into MinGW32 itself but that's another debate.

  11. And you are wrong about what MSYS is, it IS a CYGWIN fork:

    and the import libraries are almost completely incompatible with MINGW32 ones, and mixing them in a build any more complex than "hello world" will often lead to significant problems.

  12. @anon: I'm sorry I maybe harsh earlier. but now seeing that you still debating why /usr/local vs /minggw show that you don't even know how to use mingw/msys/cygwin. the path is just emulated posix path show where I put header/lib files so gcc could pick at COMPILETIME (see again moluccas page, which I DO NOT put gcc on /mingw). I have build thousand of packages using gcc for 8 years, including supplying official MyPaint for Windows. Having a reference about posix path happen all the time with MINGW, what's important is are they used at RUNTIME or not. I will not reply to you anymore. BTW I was talking about native gcc before, which part that I said "MINGW isn't CYGWIN fork"?Again sorry to offend you, but you need to do your homework first.

  13. Nah sorry, this actually looks totally screwed up. I think you are mixing MSYS and MINGW, and your incomplete patch seems to demonstrate this as well.
    FYI MINGW's BASH will always look inside MSYS for anything starting with the prefix /usr -> including /usr/local

    You don't have to reply, but I think your whole approach is wrong ans misguided.

  14. Here is a list of missing symbols using pure MinGW32 with your patch, correcting the prefix to avoid any linking to the MSYS libraries (could depend on version, but this is the gist):
    main/fopen_wrappers.o:fopen_wrappers.c:(.text+0x2a1): undefined reference to `ge
    main/php_ini.o:php_ini.c:(.text+0x119b): undefined reference to `GetIniPathFromR
    main/SAPI.o:SAPI.c:(.text+0x39e): undefined reference to `tsrm_win32_startup'
    main/SAPI.o:SAPI.c:(.text+0x3c8): undefined reference to `tsrm_win32_shutdown'
    main/network.o:network.c:(.text+0x69): undefined reference to `inet_aton'
    main/network.o:network.c:(.text+0x1e2): undefined reference to `inet_aton'
    main/network.o:network.c:(.text+0x1526): undefined reference to `inet_aton'
    main/php_open_temporary_file.o:php_open_temporary_file.c:(.text+0x36): undefined
    reference to `php_win32_check_trailing_space'
    main/streams/plain_wrapper.o:plain_wrapper.c:(.text+0x2f): undefined reference t
    o `php_win32_check_trailing_space'
    main/streams/plain_wrapper.o:plain_wrapper.c:(.text+0xf0): undefined reference t
    o `tsrm_win32_access'
    main/streams/plain_wrapper.o:plain_wrapper.c:(.text+0xeb8): undefined reference
    to `php_win32_check_trailing_space'
    main/streams/plain_wrapper.o:plain_wrapper.c:(.text+0xf84): undefined reference
    to `php_win32_check_trailing_space'
    main/streams/plain_wrapper.o:plain_wrapper.c:(.text+0xfa0): undefined reference
    to `php_win32_check_trailing_space'
    sapi/cli/php_cli.o:php_cli.c:(.text+0x1682): undefined reference to `php_select'

    sapi/cli/php_cli_server.o:php_cli_server.c:(.text+0x4e05): undefined reference t
    o `php_select'

    The requests for win32 objects not included by your configure script and open dependencies on posix symbols like inet_aton, as well as incorrectly handled dllimport macros all bespeak of linking against MSYS libc not MinGW libc.

  15. This is an MSYS port -> NOT a MinGW port.

    1. LOL Msys port? so my binary now depends on msys-1.0.dll?
      LOL you dont know inet_* wrapper for winsock? look around harder!
      oh please, so this turn out because you CAN'T compile it yourself... FFS I have wasting my time commenting on my 4 years old article.


  16. Hah. Tried the binary too and a virus was detected (MS Security)

    In any case, the patch is totally broken if for MinGW.

    One of the worst ports I have ever seen for MinGW actually -> very broken.

  17. BTW if building a port requires additional libraries or modifications to stock MinGW (e.g. "inet_* wrapper for winsock"), those all need to be specifically documented.

    Also BTW, since your own patch actually tries to undef inet_* in php_config.h -> so nobody should be needing extra wrappers for anything when the patch intent clearly shows the function isnt supposed to be used anyway.

    Your right this is a waste of time, very messy, incomplete and confusing to say the least.

    1. https://sourceforge.net/projects/tumagcc/files/0.8a/M08-net.7z/download
      Go find php.exe there which not UPX'ed.

      Think about it for a moment how do I felt 4 years ago? I respond your comments without seeing my own patch or the source, why? because I had no interest on it anymore. Now you dragged me into my past? No I'm not following you.

      1. You failed to compile it as *static* binary
      2. You failed identify the binary as native executable
      3. You failed to run/use it
      4. You complaining about something that obviously unsupported at the time

      Go ahead and say whatever it fits under your anonymity. I don't care.


    2. So far you have made me laughed when you try lecture me about MSYS stuff otherwise you make me mad with your shenanigans. Me too act ignorantly but with valid evidence and reasons.

      But this: https://www.virustotal.com/en/file/718ba699454ad104b7ab7f2f0dade2de95b2f847e6ca57a2567d1d9c6acf4065/analysis/1455864928/
      You really reach my boiling point when you abruptly try assasinate my reputation there (claiming the binary had virus after declaring the binaries was msysport).
      Therefor from now on I (as sole author of the blog) will remove any of your followup comments, If you have maturiy, identity and *actual competence* regarding compiling please reach me privately like a men.

      You want the toolchain that I used (just in case)? https://sourceforge.net/projects/tumagcc/files/0.8a/
      I'm not joking when I said have built thousand packages, above is the proof. I compiled most of it from scratch including all compilers (except msysdev) and many additional msysports (that time MSYS2 didn't even exist!). Combined with my other builds https://sourceforge.net/projects/pygobjectwin32/ that's easily exceed a thousand.

      It must be frustating unsuccesfully compile it. Me too 4 years ago, with no prior guide and no easy to use MSYS2 but I *did* my homework and overcame it (admitedly with ugly patch as I wanted a static binary and I don't want to messed wih autotools) while you in another hand showing off your confusion, baseless accusation and blatant lies. I avoided being technical here partly because obviously I don't quite remembered it anymore, but more importantly it all started when you failed to understand what a native win32 executable is, from there everything else should be put on hold. I backed up my patch with actual binaries! and FYI If I want I can dismiss all your comments simply by saying *it works for me!* just like the way you dismissed a valid evidence (the binaries).

      Ahhh talk is cheap and I talked too much but it put me on relieve. Thank you for reading.

  18. Even if we set up your famous build environment it failed because - instructions provided in your "build.txt" are more than useless.
    - More information should be more interesting.
    - All your patches are not well-formated. I have to reformat them so I could apply them. Then it works!
    - No informatin about how to set up all things.
    Your binary works indeed but this article could be more usefull with more info.
    What are we supposed to do for vsnprintf and inline functions?
    Your "builds.txt" file didn't provide enough information.
    Your binary does not stop to spam about messages with snmp :(

    Well :(

    My two cents.

  19. Сonfirm - I can not also compile php 5.4.45 with patches available here ...
    Do you have a buildroot that is compiled correctly?