Using Homestead, I try to run the BIGINT example #5 from the PHP docs and I get an "Integer overflow notice". The flag JSON_BIGINT_AS_STRING is ignored, and the result is invalid (a maximum bigint of 9223372036854775807).
The Homestead instance has the following software stack:
PHP 5.6.9
JSON 1.3.6 with JSON-C headers and lib 0.11.99.
I then tested it on 3v4l, and it works. I don't know their JSON setup.
I then tested it on OS X's pre-installed PHP which is:
PHP 5.5
JSON 1.2.1 and no JSON-C headers/lib.
This works, too - just like in the docs.
Subsequently, I found this issue which leads to this commit and seems to be what's causing the problems here, but why does Remi invalidate >64bit numbers and call integer overflow, despite the default JSON extension (present on 3v4l and OS X natively) not doing that? Doesn't this violate the claim that it's a "drop in replacement"? In its current state, this extension, which is included by default in many installations, goes directly against PHP's official documentation.
Are there any good solutions for this that don't require internal alteration of libraries used, like Guzzle?
Edit: Upon searching further, I have found this which confirms that one developer's opinion is the cause of problems here.
Yes, it's really just Remis opinion here. That way it clearly is not a 100% drop-in replacement. You ask why it's allowed? Because nobody can disallow a free developer to write his own code the way he wants.
So… all you can do is complaining and compiling ext/json yourself (instead of using JSON-C).
That means cloning from php-src source (https://github.com/php/php-src), checkout PHP-5.6 branch, navigate into ext/json directory and compile via phpize && ./configure && make install. Then add that extension to your php.ini instead of the json-c extension. [If necessary, you may need to first install some compiling tools...]
Note that with PHP 7.0 the json extension is replaced by a new implementation (see also the RFC: https://wiki.php.net/rfc/jsond), which doesn't have these issues and additionally has no license problems.
Related
I tried to import data from XML file using the importDump utility...
root#aace30d9b5f3:/var/www/html/mediawiki-1.36.1# php ./maintenance/importDump.php mrwiki-latest-pages-articles-multistream.xml
Got this error:
MWException from line 2108 of /var/www/html/mediawiki-1.36.1/includes/parser/Parser.php: PCRE needs to be compiled with --enable-unicode-properties in order for MediaWiki to function
I downloaded the source code of PCRE and run make / make install but that did not work. I am using the official docker image of mediawiki if that matters.
https://hub.docker.com/_/mediawiki
update:
I need to simplify what I am trying to ask...
Is PCRE compiled using --enable-unicode-properties in this dockerfile?
https://github.com/docker-library/php/edit/master/7.3/buster/apache/Dockerfile
Is that php image being used by mediawiki official repo?
https://github.com/wikimedia/mediawiki-docker/blob/51105612d2e1168f1b0545f47951847d63fb9613/1.36/apache/Dockerfile
PHP, unfortunately, usually uses its own PCRE library (from the manual: "By default, this extension is compiled using the bundled PCRE library"), as you can also see in this other answer.
What you need to do is recompile PHP itself in order to activate the PCRE changes. To do this you need to (you can do this on a cloned machine)
check out the exact PHP version
download and install the relevant source packages
get the exact compilation options from phpinfo()
change the PCRE options appropriately
make (you don't need install as you're not going use PHP in the cloned machine)
The only file that you need to change now is the basic PHP binary (/usr/bin/php, watch out for alternatives symlinks). If you used a cloned machine with the same distro and versions, you can easily rename that one binary on the original machine and move in the new one, and it will work (I've done this dozens of times), so you'll have the option to go back at any time.
Or you can install the development packages for PCRE on the cloned machine and supply --with-pcre-regex= and --with-pcre-dir= to the compiler. The new PHP binary will now use the system PCRE, so that pcretest -C will now yield reliable results. I am not sure whether you need the same PCRE version on both machines (you probably need the same major version, but a minor version mismatch shouldn't be a showstopper). Be aware that updating the system PCRE library might break compatibility with PHP if for any reasons the library calls change.
I have just installed the new OSX Mojave and as you know it comes with PHP 7.1.19 pre installed with just few extensions available.
First of all, I am not a fan of homebrew or any other package managers as well as disabling security utils i.e. csrutil.
I have successfully compiled intl extension but apache doesn't load it due to a code signing problem:
PHP Startup: Unable to load dynamic library 'intl.so' - dlopen(intl.so, 0x0009): code signature in (intl.so) not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. in Unknown on line 0
Is there a way to sign the newly compiled extensions, probably using ad-hoc signing method or something?
I know there are lots of other topics about this issue but all are left unanswered or at most suggesting homebrew kind of workarounds!
Thanks
After days and days trying to get intl to work with the built-in php I ended up with a robust solution!
First I must say that this answer has nothing to do with code signing!
Here is what I have done, I ignored the built-in package( php, apache ) and compiled both from source and now I have the latest version of both installed with intl extension running like a charm, building new extensions is a piece of cake and php runs them without nagging :)
I don't really understand why people use homebrew for such a thing while you can easily compile libraries and extensions yourself.
I hope this answer helps someone out there.
I also have same problem. Everybody resolves the problem with homebrew...
codesign -vd /usr/lib/php/extensions/no-debug-non-zts-20160303/x.so
/usr/lib/php/extensions/no-debug-non-zts-20160303/x.so: code object is not signed at all
codesign -vd /usr/lib/php/extensions/no-debug-non-zts-20160303/opcache.so
Executable=/usr/lib/php/extensions/no-debug-non-zts-20160303/opcache.so
Identifier=com.apple.opcache
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=2914 flags=0x0(none) hashes=87+2 location=embedded
Platform identifier=5
Signature size=4485
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=68
codesign -vd /usr/lib/php/extensions/no-debug-non-zts-20160303/xdebug.so
Executable=/usr/lib/php/extensions/no-debug-non-zts-20160303/xdebug.so
Identifier=com.apple.xdebug
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=1985 flags=0x0(none) hashes=58+2 location=embedded
Platform identifier=5
Signature size=4485
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=64
Attempting to compile PHP in Windows with Visual Studio 15 (community edition) results in
Checking for bison.exe ... <not found>
All I'm after is a version of php_pdo_sqlite.dll that includes the soundex() function. See this for the PHP 5 method I used.
I do know that VS Code is insufficient, and that installing VS 15 community does not add the path to cl.exe. Because I only need to go through this exercise to get the dll I am grossly unfamiliar with Visual Studio. Where is bison.exe? [And yes, I know that soundex() is in pdo_sqlite in *nix.]
It's possible that bison.exe (or the related files) is not on your system. In that case #Dmitry (and others') suggestion is correct.
However, another fix is to launch the Developer Command Prompt in VS15 and be sure to run {rootdir}\bin\phpsdk_setvars.bat before you run configure. This solved my issue.
Are you looking for this fellow? It's a parser generator (in case you didn't know) built for windows platform. You'll have to install the binary somewhere in your PATH, so that VS could find it.
I'm using Ubuntu 12.04 LTS and needed PHP 5.4 so I'm using Ondřej Surý's (php5-oldstable) package.
Both phpinfo and the CLI show that JSON is enabled:
#php -i | grep -i json
json
json support => enabled
json version => 1.2.1
My application mostly works. But periodically (approx one page refresh in ten) there is a PHP error. This only happens intermittently.
PHP Startup: Unable to load dynamic library '/usr/lib/php5/20100525+lfs/json.so'
- /usr/lib/php5/20100525+lfs/json.so: cannot open shared object file:
No such file or directory "json.so"
How do I fix this?
I think that possible culprit (as I have answered in email) is that you are loading json extension somewhere from the configuration file.
The JSON extension is compiled in the core for PHP 5.4, so you should not load it by hand.
Please check that you don’t have:
json.ini somewhere in the /etc/php5/{mods-available} left over from previous PHP 5.5 installation
you are not loading JSON extension from the mentioned script, e.g. no dl(json.so).
Make sure you have stopped and started Apache2 (same applies to php5-fpm) when changing major versions. The symptoms might indicate that there was some stuck Apache2 thread with previous PHP from package loaded (that would be PHP 5.5 with json-c based JSON extension in this case).
Since you're saying that the json extension is loaded in phpinfo()'s output you could be dealing with a bug. Have you checked if the module file is actually there in the filesystem?
You have the following options:
Compile PHP 5.4 from source with Apache 2.4
Upgrade to the same repo's stable version which will give you PHP 5.5 + Apache 2.4.
Submit a bug with the Ondrej in Ubuntu's PPAs and wait for it to be resolved.
For more information check the debphp site.
Submitting a bug is a must, since if it is a real one it must be fixed for all users.
You could firstly go with option 2 if you don't conflict with the Migration guidelines like backward compatibility, deprecated functions, etc.. SO check it and decide.
It also strongly varies depending on the machine you have to do this with. If it is a critical production server, you may not want to compile of change versions on it. Go file the bug and see what the package maintainers have to say about this.
Also please write a reply here when your problem is resolved. I am quite curious as to what it is and hopefully was. :D
One point that doesn't diagnose or solve the issue (and seems to refer to PHP 5.5), but might help with tracing its root cause:
This Debian bug report and Phil Sturgeon's blog explain that some Linux distributions have chosen to replace the official PHP implementation of ext/json with the drop-in compatible pecl-json-c. The rationale was that Douglas Crockford's implementation contains a non-free clause in the license ("The Software shall be used for Good, not Evil"). See also this blog post.
I have an inconsistency, and I could not align their versions properly, so I just wanted to remove the library version. Can I do this? Is the header version for PHP while the library is from my distro? Can I upgrade PHP's library version? If so, how? I am using PHP 5.4.4
For example,
Is the header version for PHP while the library is from my distro?
It means it was compiled against the 1.0.1 headers, but is now dynamically linking against 0.9.8. So you are using an older version than what was used when PHP was compiled.
Many libraries store the version in the header files. So when a program uses the library, it can do something like int HEADER_FOO_VERSION = LIBRARY_VERSION, which embeds that version number into the program (e.g., php). Now when that program runs, it links dynamically against the library, which may be a different one than was on the host system.
That library may have a function call, say int get_library_version(). So the program (PHP) can check if HEADER_FOO_VERSION == get_library_version(). If it's different, then there could be a compatibility issue. (Of course, it doesn't have to be assign to a local variable... I'm just trying to drive home the point that the header version number can be compiled into php, and remains constant no matter which version of the library is being used at run time.)
Whether or not it is a problem depends on if the two versions are compatible.
Usually if the library is > than the header, you are okay. It's definitely more likely to be a problem if the library is older than the version it was linked against. Of course, this is because it's impossible to know what changes future versions may have.
So in your case, I would try to update your system's SSL libraries via apt-get, yum, etc, to match the version PHP is expecting.
To check which version php is using on Linux:
$ ldd `which php` | grep ssl
libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0
Note that which php is just a short-cut to find the full path. You can hard code any executable you'd like to check: ldd /usr/sbin/httpd.
I dont know the answer myself, but when searched on google some nice resources explaining the same.....
What's the difference between a header file and a library?
The version of the files are the one mentioned in the phpinfo used to create a library.
Hope it helps, there are lot of resource available if searched on google.
Still will like to hear from someone in great details about the question
The header version is the functionality version, whereas the library version is the code version.
The header defines the interface - it tells you what functions are within the library. If a header gets updated, then you need to check to make sure all the functions are the same, and see if any are added or subtracted.
But if a library gets updated, and not the header, it means all the function calls are the same, but some of the code may be changed (eg, bug fixes).
In your example, PHP is seeing functionality for OpenSSL 1.0.1, but the actual version of the source code that OpenSSL is loading is 0.9.8o
This is commonly seen on updated versions of openssl. What happens is the newer versions for the libraries are stored in different folder. The original folder located at /usr/bin/openssl would need a symbolic link to the new folder /usr/local/bin/openssl. That would get both to be the same version or just show OpenSSL Version _(Whatever)
Normally there is no concern for this, since it still works the way it is intended. This is seen a lot on shared servers.
EDIT:
The information in this post is generic and can be different if you are running
CentOS, RedHat, Ubuntu, or another Linux/BSD version. Check documentation or man
pages for the best information
If you do update your OpenSSL, some versions of *nix Require for you to rebuild PHP and Apache for it to update
If you are rebuilding PHP from source, I have found another possible reason for a mismatch. It's so simple yet if you are not familiar with building from source on Linux, not knowing it can cost you a lot of time.
The answer is here: https://serverfault.com/a/567705/305059 - unfortunately I cannot up-vote it over the not-so-useful answer, so if you have the reputation there, please do.
You need to run "make clean" before "make" in order for it to rebuild all binaries. Strangely, without this step I was getting an updated library version, but the old header version - so I think it must have rebuilt something, but not everything. My rebuild involved linking to a version of curl in another location (built with ssl), which might be the reason behind it.
Anyway, I hope this helps someone. Thank you to #velcrow on serverfault.