The CLI version has readline support in interactive mode (good for learning) similar to those linux build.
Configuration:
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=-lodbc32Autotools 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)
Thank for PHP CLI!
ReplyDeleteCan you compile it without SNMP support so no MIB warnings will be given? Thanks in advance!
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.
ReplyDeleteregards,
thank you very much
ReplyDeleteThis comment has been removed by the author.
ReplyDeletecould you please compile php with --enable-pcntl and --enable-posix ,then d11wtq / boris would run on windows.
ReplyDeletelinks :
https://github.com/d11wtq/boris
http://www.php.net/manual/en/pcntl.installation.php
Hi 王思,
Deletewhile it's possible to use posix thread in mingw, it doesn't mean other posix features can be enabled.
can we compile latest php 5.7-dev with mingw?
ReplyDeleteI 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
DeleteI'm just visiting php.net and seeing only 5.5.x-dev series? are you sure there such 5.7.x-dev ?
Delete5.7-dev is not official release. it's come from latest source and i do build with vs. With GCC? :(
DeleteBonek
would you please tell us how to build php from source under mingw step by step?.
ReplyDeleteBefore that, first a proper autotools patch needed. Mine is just screwed up :D I wasn't familiar with those *.ac *.am files back then.
DeleteAlso more importantly How much interest the upstream developers have to maintain a mingw port?
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
DeleteGreat work!
ReplyDeleteI 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?
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.
Deletecurrently 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.
ReplyDeleteThat's good news.
DeleteAs 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.
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.
ReplyDeleteErrrr.. 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
DeleteAnd 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.
DeleteCool, 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.
ReplyDeleteAnd you are wrong about what MSYS is, it IS a CYGWIN fork:
ReplyDeletehttps://sourceforge.net/p/msys2/wiki/How%20does%20MSYS2%20differ%20from%20Cygwin/
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.
@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.
ReplyDeleteNah 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.
ReplyDeleteFYI 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.
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):
ReplyDelete.....
'
main/fopen_wrappers.o:fopen_wrappers.c:(.text+0x2a1): undefined reference to `ge
tpwnam'
main/php_ini.o:php_ini.c:(.text+0x119b): undefined reference to `GetIniPathFromR
egistry'
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.
This is an MSYS port -> NOT a MinGW port.
ReplyDeleteLOL Msys port? so my binary now depends on msys-1.0.dll?
DeleteLOL 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.
TRY TO RUN THE BINARY AND GET A CLUE!
Hah. Tried the binary too and a virus was detected (MS Security)
ReplyDeleteIn any case, the patch is totally broken if for MinGW.
One of the worst ports I have ever seen for MinGW actually -> very broken.
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.
ReplyDeleteAlso 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.
https://sourceforge.net/projects/tumagcc/files/0.8a/M08-net.7z/download
DeleteGo 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.
DeleteSo 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.
Even if we set up your famous build environment it failed because - instructions provided in your "build.txt" are more than useless.
ReplyDelete- 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.
Сonfirm - I can not also compile php 5.4.45 with patches available here ...
ReplyDeleteDo you have a buildroot that is compiled correctly?