This only occurs on IIS 7.5 server on Windows 7 (on linux decimal point is set just fine).
$locale = setlocale(LC_ALL, 'pl_PL.utf8', 'pl_PL', 'pl', 'polish');
echo $locale;
echo strftime('%B');
print_r(localeconv());
Output:
Polish_Poland.1250
grudzień
Array (
[decimal_point] => .
...
)
As you can see:
Locale are set ok
Month prints just fine
Decimal point is . while it should be ,
PHP is VC9 TS running as FastCGI module, tried running from CLI with the same result...
Any idea why and if there is a fix?
If this is happening at the CLI level, then I'd say this is a bug in PHP and should be reported (http://bugs.php.net).
Before you do, however, you should take the following steps so they won't yell at you:
Make sure you're running the latest stable version of PHP (5.3.8)!! They'll ask you for the version, and if you're using an older one, they'll probably just mark it bogus and tell you to download the current version.
Repeat the test in Linux using the identical script. The result will tell you whether the bug is specific to the Windows build or not. If it is, it may or may not be a problem with Windows itself (in which case Pierre might get a bit annoyed), but I'd say it's still worth posting so that there's a record of this issue on the bug tracker.
This isn't required, but converting your script to a PHPT file and then posting that might get you a more prompt response.
If possible, try replicating this bug on a separate Windows box so that a problem with your OS configuration can be ruled-out. You can of course skip this step if the bug occurs in Linux as well.
Once the bug is posted, please post a link to it here. You'll probably get responses asking for additional information, so keep an eye on it and be prepared to do so without too much delay.
This process will confirm whether or not it's a bug in PHP. If it is a bug, then your report will lead to a fix in the next release. If a hotfix is posted, I could patch that into the source and send you a custom build to use until the next version is released.
Oh and on an unrelated note, you should not be using the ZTS build of PHP on IIS/FastCGI! I don't think this is related to the problem you're having, but you could run into other problems (performance decline, random crashes, etc) if you continue using that build. What you want is the NTS (non-thread-safe) build.
Here's the basic rule of thumb for running PHP on Windows:
Apache: Thread-safe (ZTS)
IIS ISAPI: Thread-safe (ZTS)
IIS FastCGI: Non-thread-safe (NTS)
Related
I am developing a Laravel 9.x app in Windows 10. My current version of PHP is PHP 8.1.5 (cli) (built: Apr 12 2022 17:38:57) (ZTS Visual C++ 2019 x64). Is this a thread-safe or not-thread-safe version? How can I tell? When should I prefer a thread-safe over a not-thread-safe version?
I've tried researching this issue here on StackOverflow but the questions/answers I see all seem to be a decade or more old - like this - and I strongly suspect that I might get a different answer if I asked the question today simply because the technology has changed in the intervening years. Is that a reasonable assumption? (At the very least, my current version of PHP evidently uses a newer compiler, VC++ 2019, rather than VC6 or VC9.)
I have no idea yet what my production environment is going to be or even IF the app I'm developing will ever go to a production environment since it's just an app I'm writing to (re-)learn Laravel. I may put it in production as a demonstration of a working Laravel app when the time comes but whether it will be on a hosting service or Netlify or something else, I just don't know at this point.
Just to give you some context, this issue only came up because I am trying to learn how to step through my Laravel source code to debug problems and this apparently requires me to add XDebug to XAMPP. The instructions I found for installing XDebug point me to here and recommend that I download the Windows binaries for my version of PHP. There are no binaries of 8.1.5 so I don't know if one of the binaries for 8.1 would work or if I'd be better to use 8.1 thread-safe or 8.1 not-thread-safe. If it would be better to upgrade my PHP first to 8.2, I still don't know if thread-safe or not-thread-safe is a better choice.
Can someone enlighten me on these matters?
Is this a thread-safe or not-thread-safe version? How can I tell?
You can use the good old phpinfo() function and lookup for the Thread Safety column.
If you have your PHP setup in PATH environment, you can even get it via CLI using a quick command php -i | grep Thread
When should I prefer a thread-safe over a not-thread-safe version?
As per PHP official documentation
If you choose to run PHP as a CGI binary, then you won't need thread safety, because the binary is invoked at each request. For multithreaded webservers, such as IIS5 and IIS6, you should use the threaded version of PHP.
I have no idea yet what my production environment is going to be ...
Generally, there is no difference on TS or NTS code execution. It's more towards the webserver.
If I am not mistaken, by default, XAMPP uses Apache Handler, so it will likely be a thread safe build. And yes, the Xdebug binary for PHP8.1 will just work fine.
Technically, NTS should be slightly faster because it doesn't need to cater for thread safety.
Personally, I think it doesn't matter, unless you want to spend slightly more time to tinker around the webserver switching to FastCGI or PHP-FPM, since you are still in development phase, I think stick to the default setup and focusing on getting it up is more efficient.
I'm using Windows 10 Home Single Language 64-bit Operating System on my laptop.
I've installed the latest version of XAMPP on my laptop.
This has installed PHP 7.2.8 and Apache/2.4.34 (Win32) OpenSSL/1.1.0h PHP/7.2.8 on my laptop.
I come across following sentence from PHP Manual Page :
PHP can be used on all major operating systems, including Linux, many
Unix variants (including HP-UX, Solaris and OpenBSD), Microsoft
Windows, macOS, RISC OS, and probably others. PHP also has support for
most of the web servers today. This includes Apache, IIS, and many
others. And this includes any web server that can utilize the FastCGI
PHP binary, like lighttpd and nginx.
From the above text I didn't get the exact meaning of the term "PHP binary". This peculiar term is used very frequently at many places in the PHP Manual but nowhere the actual meaning of "PHP binary" has been given.
I googled it for the meaning and I come to know about the 'predefined constant' PHP_BINARY.
So, I tried to execute the below code in hope to clear my doubt over the actual meaning of the frequently used term "PHP binary" and checked the output in my web browser:
<?php
echo PHP_BINARY;
?>
Surprisingly, I got the below output :
C:\xampp\apache\bin\httpd.exe
I got surprised to see this output because in output I got complete address of the Apache file httpd.exe. I was expecting to get something about PHP but I got Apache file's address. Why so?
So, what does ultimately mean is I still don't understand what does actually mean by the frequently used term "PHP binary"?
I still don't have any idea about what does actually mean by the very frequently used term "PHP binary"?
Someone, please clear my doubt about the frequently used term "PHP binary" in an easy to understand, simple and lucid language.
I'm waiting for your help.
The compiled version of any program is commonly referred to as it's "binary".
PHP has multiple binaries for multiple purposes.
php.exe is used to run scripts locally in your Command Prompt;
php-cgi.exe is compliant with FastCGI protocol;
php7apache2_4.dll is PHP wrapped as an Apache 2.4 module;
And a few others too.
In this case the docs are referring to php-cgi.exe
The constant PHP_BINARY contains the path of the binary where PHP is currently executing from. Since XAMPP uses Apache, and Apache is most likely using PHP in it's Apache module form, it makes sense that httpd.exe is recognized as the binary, since it is loading php7apache2_4.dll.
PHP itself is running as a program on your computer (often referred to a binary).
Supposed we were on Windows, the PHP binary would probably be php.exe. Essentially, PHP itself.
Note that the PHP binary could be a server module... a DLL or similar.
So I have a Portable Webserver program called USBWebserver,
because the original program still uses php 5.3 (I believe) I went on an adventure to upgrade it so that not only me but the rest of my class can use it.
I upgraded the Apache server build to 2.4.27
I upgraded the PHP binary to 7.1.9
The thing is... Everything functions but one thing:
For some reason MBString (Yes, just MBString) will not start up with a variable path anymore. If I set a manual path it functions it just no longer does this with a variable one.
Before people say:"Then why don't you just make it a manual path and be done with it." because it needs to stay portable and usable "out of the box" so to say.
I am quite stuck on how to fix this issue. If any info is needed, please ask and I will edit this post with the info. (Like if you need php.ini)
After a lot more messing about with it I finally found out what fixed this issue. I'll post it here so that others who might try to do this won't have this hurdle to combat.
extension_dir's path at first was "php\ext" as php.exe wasn't liking that I changed it to ext, which php.exe liked but apache...not so much.
After a long while I changed the path to extension_dir = ".\php\ext" and as if the gate of heaven opened... it functioned. Fully and completely without even one error.
So now I have a modified USBWebserver running:
PHP 7.1.9
Apache 2.4.27
PHPMyAdmin 4.0.4.2
MySQL 5.6.13
Fully portable, fully fuctional. I hope this little tid bit of info helps someone else some day and if some people want the program, ask and I will make a download link and edit it into my original post any this answer.
Have you been updating usbwebserver to newer version?
It seems that the officiel development has stopped.
I have tried to update php to version 8, but then the apache server won't start, and there is noting in the log file - its just empty.
Thanks
Jorgensen
I have huge PHP script which I have been running on Apache 2.2.12 and I have recently upgraded to Apache 2.2.14. However, my PHP script doesn't work as it stops at a certain point all the time. I have been trying to work out what the difference is in these two Apache versions, I have looked at this CHANGELOG and have not been able to determine this.
When I look in my Apache error log, I find this before my PHP script fails to do anything else.
Parent: child process exited with status 255
The errors after this are just notices and they end after a few of these.
What changes in Apache do you think can cause this? I was reading around and I found a few people saying that newer versions of Apache on Vista (windows) can detect when a PHP script is in an infinite loop and will kill that child, is this true?
Thanks all for any input.
Update
Apologies, this is no longer relevant. I think its a PHP issue. I switched from 5.2 to 5.3 and I think its do with modules. I will be openning another question.
try this
download this
http://windows.php.net/downloads/snaps/php-5.2-win32-VC6-x86-latest.zip
then copy libmysql.dll into your php directory and restart apache
Actually it does not relate to modules, but to certain validations made by the core interpreter, which breaks many nonstrict processes in different PHP applications. Beware of updating PHP to 5.3! Mwahahahaha!
When running PHP in CLI mode, most of the time (not always), the script will hang at the end of execution for about 5 seconds and then output this:
Error in my_thread_global_end(): 1 threads didn't exit
It doesn't seem to actually have any effect on the script itself.
Some web searches turned up blogs which suggest replacing the php_mysql.dll with a different version, however this has not solved the issue for me, and I suspect the info from those blogs is now out of date.
My setup:
PHP Version 5.2.4
Apache/2.2.4 (Win32)
Windows Vista Home Premium SP1
This is a known bug with some of the PHP 5.2.X version in the windows fast-cgi implementation
http://bugs.php.net/bug.php?id=41350&edit=1
I have encountered this bug before and downgrading my PHP install to 5.2.0 solved the problem.
There is no need to downgrade the entire PHP version, just replace the libmysql.dll from the PHP 5.2.1 release & things should be rolling :) Refer this link for more info.
Did you take a look at this resource? You may want to double check that you got a specific libmysql.dll (5.2.1) that is unaffected by this, and also to double check that you don't have any stray mysql libraries lying around that PHP could be picking up instead. Or, switch from FastCGI if that's an option for you.
For interests sake, the bug appears to be best detailed here. The general idea of the problem (from the mysql bug link) appears to be:
Whenever a new thread is created libmysql is told about that by Windows. It then
increases a thread counter and initializes some data. When libmysql is being unloaded
it checks whether all threads have finished, if not it tries to tell them "close now"
and gives them 5 seconds for that. In general this works in a nice way.