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
Related
I just got handed a big project running Symfony 3.4, and PHP 5.6, that I'm trying to get working on my "new" Mac Catalina (just purchased and installed, not upgraded from a previous macOS version), and I've gotten things working up to a certain point:
our-symfony-3-project $ bin/console server:start
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.64.dylib
Referenced from: /usr/local/opt/php#5.6/bin/php
Reason: image not found
zsh: abort bin/console server:start
I was able to fix a previous similar error with needing openssl 1.0.0 (I had to compile it from source using Homebrew then link it), and I think the solution is the same here, but it appears that I need to find the library or repo or download for icu4c version 64 (not sure I'm reading this right) to get brew extract to install it (it won't any other way), or figure out how to compile it and manually get it working for PHP 5.6, and I'm not finding the library I need apparently.
I've gone through pages and pages and probably a hundred command attempts trying to fix this error... and so far the recommendations have either been outdated (due to macOS/brew changes), or just didn't work.
I'd like to know where I can find the appropriate file/download/repo to just be able to install or compile this through brew or otherwise. PS: I know we shouldn't be using old versions but I just got this job and the company will not upgrade for a while.
I'm answering this by saying that I got the repo to work on a PHP 5.6 host using MAMP Pro (and Apache, not that that's relevant)... which already had the required libraries in question.
I went through the docs on the trial version (version 6.3.2):
https://documentation.mamp.info/en/MAMP-PRO-Mac/Settings/Hosts/General/
However, unlike Homebrew, switching PHP versions across hosts in MAMP Pro doesn't overwrite PHP symlinks like brew unlink and brew link does, I have to still edit my .zshrc file aliases and my PATH to have things like php (or pecl or pear etc) point to the MAMP Pro PHP version folders to get them to work correctly with the repos, as well as with composer (which runs the php command). Even MAMP's documentation says to modify the files yourself...
I can't tell yet if this difficulty is just natural to having multiple hosts with different PHP versions configured, as I could see how multiple variations running at the same time could conflict if they're using the same system files (like /usr/local files)... which sound like system software dependencies, and I don't know that these dependencies could be relegated to their own host folders (like /Applications/MAMP/bin/php/php5.6.40 folders), or maybe I just missed something somewhere. I'll update this answer if I learn better what to do here, or will add another answer if I find a way to do them using Homebrew better.
Maybe I'm running low on coffee, maybe it's just because it's Monday, but for the life of me I'm unsure of what I'm doing wrong. I've installed php-snmp.x86_64 5.3.3-47.el6 via yum, updated php.x86_64 to 5.3.3-47.el6 as yum required and restarted apache, but I'm still unable to create a new SNMP object like so (assume variables are instantiated beforehand):
$snmp = new SNMP(SNMP::VERSION_2C, $ip, $community, $snmp_timeout);
Error log states "PHP Fatal error: Class 'SNMP' not found". People on various forums are saying it's only available in PHP 5.4, but if that were the case why was I able to install it? The PHP SNMP installation page states "SNMP support has been restored in PHP 5.3.3."
I'm hoping that this is just one of those stupid mistakes that can be fixed with a missing include, but what am I missing here?
PHPInfo (from apache, not CLI) notes the following regarding SNMP:
Configure Command: --enable-ucd-snmp-hack
Additional .ini files parsed: /etc/php.d/snmp.ini
NET-SNMP Support enabled
NET-SNMP Version 5.5
Installing that module allows you to use the SNMP functions in PHP. Most of them have been around forever (like, the PHP 4.0 days) and certainly don't require SNMP 5.4. They are just basic wrappers around the C API functions and don't provide any object-oriented access to SNMP.
The SNMP class, on the other hand, is a new feature of PHP 5.4, so will not be available on such an old version.
I'd recommend using Remi's repository to upgrade to a modern PHP version. See this answer for details, though URLs may have changed.
I recently upgraded my Linux server from Apache 2.1 to 2.4 and PHP 5.2 to 5.3. Previously I was using pdf.so from PDFlib fine, but when I tried to install it, as downloaded from here,
http://www.pdflib.com/download/free-software/pdflib-lite-7/
PHP failed to load the module as it was compiled in for PHP 5.3. This install was done using the newest version of PDFlib that I could find, 9.0.2.
Anyone know whether this is possible? I've already got things coded in PHP for PDFlib and prefer not to use another library unless the commands are the same.
UPDATE
Has anyone successfully used PDF Lite with PHP 5.3?
You must compile it. Currently no build is available for PHP 5.3.
On the Download-Site, READ the info:
PDFlib Lite source code must be compiled to generate a usable library. PDFlib GmbH does not offer precompiled (binary) versions of PDFlib Lite.
If you have compile errors, check out the error logs - What say it? Yep, i think you need additional sources for compiling (mostly).
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 found a few related posts here but didn't get my answer. So posting again.
How would I install a PECL extension on windows? Say I want the PECL oAuth extension on Windows XP.
I know 2 methods, but none of them is working for me.
The site http://pecl4win.php.net/ is down for months. So I cant download the DLL. Is there any place we can download the DLLs from ?
running the command
pecl install oauth-0.99.9.tgz is throwing the error
The DSP oauth.dsp does not exist.
I tried with few other extensions also and getting the same error.
What am I missing here?
Releases can now be found here:
http://windows.php.net/downloads/pecl/releases/
If you need an extension not available there you might ask on the pecl-dev at lists.php.net mailing list.
I got what I am looking for in http://windows.php.net/downloads/pecl/releases/
Currently PECL for windows is in an odd reformation state. The reason being that I believe they are trying to provide VS2008 source versions. I would actually suggest using Zend Server for now until the windows half of the php group gets everything fixed up. Zend Server includes almost all of the extensions that you can find in PECL, and everything else, if you are lucky, you could find an compile yourself.
The PECL installer downloads the source code of the extension and tries to compile it with your local C compiler. The problem is that the whole process is designed for Unix systems, where a C compiler is available or can be easily installed. Setting an environment to compile C code under Windows is pretty complicate.
The ideal solution is getting a DLL file that someone already compiled. That's what the pcle4win site was for. However, there's currently no official repository to download PECL DLLs so you only have two alternatives:
Find an unofficial DLL somewhere in Google
Compile it yourself (another link) with Microsoft Visual Studio
It'd be cool that there was a DLL repository out there but I'm unaware of any.
The php source ships with a set of configuration scripts for windows (using windows script host) that mimics the autoconf tools as far as php is concerned. If you place the code for the extension in a directory under the /ext directory (where all the other extensions like bcmath, bzip, ... are located) you can let the buildconf-script create a makefile that includes the build rules for that (new) extension.
There's a step-by-step walk-through at http://wiki.php.net/internals/windows/stepbystepbuild which seems to be brief but feasible.
compiled oauth: http://windows.php.net/downloads/pecl/releases/oauth/
another pecl extension: http://windows.php.net/downloads/pecl/releases/