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.
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.
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
I am running IIS 10 with PHP 7.1 and was trying to make use of the http_parse_cookie() method in PHP Storm when I realized that PHP Storm was only providing the stubs to the PECL methods. After an exhaustive search on the web, I came across this Windows PECL repository but it only goes up to 2.5.0 which doesn't work when I try to use it.
I need php_http-3.1.0-7.1-nts-vc14-x64.zip but the only thing they have listed is some log files. Where can I reliably get the php_http.dll for PHP 7.1?
I've done tons of searches but the DLLs are nowhere to be found.
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'm running MicroApache (http://microapache.amadis.sytes.net) on Windows XP and would like to use SQLite 3 databases.
The PHP version is 5.2.9-2.
My MicroApache version has SQLite 2 support through 2 lines in the php.ini:
extension=php_pdo.dll
extension=php_sqlite.dll
I test whether the extension works in 3 ways:
1. phpinfo()
2. extension_loaded() and get_loaded_extensions()
3. using sample code that var_dump()s the constant SQLITE3_NUM (should be the integer 2)
and tries to create a database (error: class 'SQLite3' does not exist)
Things I have tried (if I can remember them all):
1. copied php_sqlite3.dll from a full installation of PHP and added "extension=php_sqlite3.dll" to php.ini
-> error "Procedure entry point gc_remove_zval_from_buffer was not found in php5ts.dll"
2. compressed the DLL with UPX (like the other DLLs of MicroApache seem to be)
-> does not display an error on start, nor in the log file, but does not work
3. tried various things with php.ini
- created a section "[sqlite3]"
- prefixed "sqlite3." to "extension_dir=." and "extension=php_sqlite3.dll"
- ...
4. tried to use PDO, it says it 'could not find driver'
Who can help me get SQLite 3 to work?
The problem of connecting to SQLite 3 DBs and similar problems are covered and discussed on a forum post entitled, "Connecting to SQLite3 database from PHP 5.25" This may answer some of your queries.
The latest build of SQLite is compiled-in to PHP5 and is enabled via PDO.
It shows in PHPINFO.PHP as
2.0-dev "$Id: sqlite.c,v 1.166.2.13.2.12 2008/12/31 11:17:44 sebastian Exp $"
Sounds more like a problem with the test code. Have you cross-checked by running on an SQLite system with standard Apache and the same version of PHP? What are the result from phpinfo(), etc?
The recent MicroApache distros come with a PHP/SQLite guestbook as a demo/test. Does this not work?
Come to think of it you may not have spotted that there's an SQLite distro. Why not revisit the site and check the other versions out (just unzip and run).
MicroApache 2.0.63+PHP 4.4.9+SQLite:
As always I point out that MicroApache isn't intended to be used on a public-facing webserver without paying specific attention to the security config. It was developed merely as a way of sharing information locally via floppy or USB stick. It's easy enough to harden though.
I'm sure you are aware that the SQLite developer renamed a number of the functions with the advent of SQLite3 including the open function - (See here: An Introduction To The SQLite C/C++ Interface ) - I'm not sure how this has been handled by the PHP developers including this codebase into PHP. The suggestion from the page linked above is that you can open PHp3 DBs "as is" with the right PHP code.
Mixing DLLs from different distros of PHP isn't recommended. I don't recommend any other use of the MicroApache distro other than "as is". Adding or mixing DLLs from differing versions of PHP etc. to MicroApache may introduce serious bugs or security problems.
There has been little or no interest in SQLite with MicroApache to date so I've really not dug too deeply into it other than to check the functionality works.
I don't rely too heavily on what's reported by phpinfo().
Perhaps you can update with your info to confirm if the version being reported is accurate.
Update
I've had time to research a little more and a discussion on php5-sqlite3 at the Mac OS Forge mailing list answers your problem.
The PHP implementation is partial and not well documented. Some SQLite3 procedural function calls are only exposed by an object based hierarchy. The procedural API only offers the ability to open SQLite 2 DBs so you're stuck with using objects by the looks of it.
There is also a PECL extension, php-sqlite3, which was
developed during 2008, currently at
version 0.6. This is what the
php5-sqlite3 port installs. But it
does not provide the sqlite3_open
function you are seeking. Rather, it
gives you an object-oriented interface
based around three classes: SQLite3,
SQLite3Stmt and SQLite3Result. It is
described here, rather incompletely,
notably the installation
instructions are totally missing:
MicroApache 2.0.63+PHP 5.2.9+SQLite
MicroApache 1.3.41+PHP 4.4.9+SQLite
MicroApache 1.3.41+PHP 4.4.9+SQLite
MicroApache 1.3.41+PHP 4.4.9+SQLite+GD2
Hopefully you can play with these distros and solve your problems.
There is an SQLite3.DLL included with the distro as a courtesy which can be accessed directly from VB5/6 or any compatible language which can call the DLL.
Using SQLITE 3 from Visual BASIC 5
This was a separate project I had a look at some while ago. This was produced in MSVC by editing the original source. This DLL isn't compatible with PHP/PDO but could be used via a CGI interface. Alternately the original SQLite 3 DLL could be obtained and used via Delphi etc.
Please be aware that I do have the distro with SQLite support. However it only has support for version 2, not 3.
My MicroApache version has SQLite 2 support [...]
I would like to use SQLite 3 because it is faster, I could interact with the databases I created for a project in Delphi and I could access the newly created databases with the Firefox extension SQLite Manager.
I've tinkered with this problem some more, but could still not create/access a SQLite 3 database.
Interestingly, the link you provided in Part 1 mentions a class "SQLiteDatabase" which is not found in the PHP documentation and is not part of the SQLite3 extension (which is object oriented - as mentioned in your last post, Mad Max).
"SQLiteDatabase" creates a database, but when you open it, you can see that it is in version 2.1.
Thanks for the help.
EDIT:
PDO works only when I use the DSN prefix "sqlite2" which is not very surprising, since phpinfo() only lists the driver "sqlite2" under the section "PDO".