I have a site that use PostgreSQL database but I found that my RHEL 5 system lacks of pdo_pgsql.so file. I have spent several hours trying to install it but it was impossible.
When using "rpm -i" command with a lot RPMs found in Internet, I always got dependencies problems.
Last command I have issued before posting here was:
rpm -i http://yum.postgresql.org/9.1/redhat/rhel-5-i386/pgdg-redhat91-9.1-5.noarch.rpm
The output to that command was: package pgdg-redhat91-9.1-5 is already installed
And in fact, PostgreSQL database is up and running. The only missing file is pdo_pgsql.so.
I have used "find . / -name pdo_pgsql.so" to see if that file is somewhere in the disk, but without success.
Can you point me to the right direction, please?
These are relevant versions:
psql (PostgreSQL) 9.1.2
PHP 5.3.27 (cli) (built: Dec 8 2013 19:01:03)
Server version: Apache/2.4.1 (Unix)
Red Hat Enterprise Linux Server release 5 (Tikanga)
Cheers
Jaime
I have recompiled last PHP version with Postgres support option and the problem was solved. However, it is strange, because version of PHP I had before worked with postgres. For some reaon, it stopped working,
Related
I install php via brew. With brew install PHP. My version of php-cli is 7.2
But, if I use phpinfo() on my server, I get php version 7.1.
If I use php -v in my terminal, I get php version 7.2.
Disclaimer: I'm adding this hopefully extensive answer as part of the Revival badge. (Answer more than 30 days after a question was asked as first answer scoring 2 or more)
TL;DR
php -v settings can be different from phpinfo() inside your web-server due to the running service state of fpm and your webserver. Perhaps you need to restart php-fpm and/or your web-server (apache, nginx, ..).
Long version: Command line
Command-line based calls like php -v or php -i or php test.php will read your configuration, options and arguments every time you execute your script within a terminal.
This means if you update php in your operating system then you'll get the most recent version in your terminal session.
Attention: Depending on your PATH variables you still might get an older version.
What does this mean? Even if you update your php version on your operating system you might still have an older terminal session which links to an older php-binary.
Here is an example: I am an OSX user and installed php through brew. Currently php links to php#7.3. Here is my way to validate which versions are running where. For this I'm using which php.
$ which php
/usr/local/opt/php#7.3/bin/php
$ php -v
PHP 7.3.11 (cli) (built: Oct 24 2019 11:29:42) ( NTS )
// or the equivalent "absolute path" example
$ /usr/local/opt/php#7.3/bin/php -v
PHP 7.3.11 (cli) (built: Oct 24 2019 11:29:42) ( NTS )
I have multiple php-versions installed on my local system. I can run them all individually. Here is an example:
$ /usr/local/opt/php#7.2/bin/php -v
PHP 7.2.20 (cli) (built: Jul 5 2019 12:56:54) ( NTS )
Long version: Why is my phpinfo() using the wrong php version?
Since we now have an understanding that we can run multiple and different versions of php on a single operating system, lets dig into our web-server based script which runs phpinfo().
After installing a new php-version you'll have your binaries replaced by new versions. Awesome! but.. how does my running web server get notified about it?
For this I'll refer to the php documentation Apache 2.x on Unix systems Point 7. Also apache allows us to load different modules for PHP.
Edit your httpd.conf to load the PHP module. [...]
For PHP 7:
LoadModule php7_module modules/libphp7.so
For PHP 5:
LoadModule php5_module modules/libphp5.so
Since you are upgrading from PHP 7.1 to PHP 7.2 there is probably no change but your webserver is still running the old linked version of php.
In this case a restart of your apache webserver should help so it can pickup the new binaries correctly.
Please let me know if this will help you to solve your issue. For all the other readers: If you think there is something missing OR there is something wrong in my explanation then please let me know with a comment.
When I check my php version I get the following warnings:
PHP Warning: PHP Startup: ssh2: Unable to initialize module
Module compiled with module API=20121212
PHP compiled with module API=20131226
These options need to match
in Unknown on line 0
I'm trying to understand which versions work together and how I can get hold of the correct version to setup PHP with SSH2. I have been able to find the .tar.gz versions of libssh from places like the following:
https://www.rpmfind.net/linux/RPM/remi/enterprise/6/x86_64/php56-php-pecl-ssh2-0.12-4.el6.remi.x86_64.html
The problem is I am using a Windows machine and not Linux. Does anyone know whether I can get the same libssh version for Windows? Or do I have to downgrade PHP to the same level as ssh2? Or is it nothing to worry about it and just a quirk of Windows?
Here are some details that might be of use:
OS: Windows 10 (x64)
PHP Version: PHP 5.6.15 (cli) (built: Oct 29 2015 12:39:50)
Microsoft Visual C++ 2015 Redistributable (x64) 11.0.61030
Server version: Apache/2.4.17 (Win64)
Apache Lounge VC11 Server built: Oct 13 2015 11:37:51
In addition... I've found the version of the ssh2 zip that I downloaded. It was 5.5 Thread Safe (TS) x64 from: https://pecl.php.net/package/ssh2/0.12/windows
So, I guess that means I need to downgrade my PHP to 5.5 for this to work properly. Is that correct or is there a better way?
I've found a solution to the problem. As stated in the OP the problem was that the PHP module was a later version than the SSH2 module. The question was how to find the versions that would work with the setup stated. This proved to be quite tricky because there were more systems that needed to be integrated than I first thought. I falsely assumed that the latest versions would all play nice together.
As I am running Windows 10 64-bit I wanted to get the stable version of PHP that runs against this - that would be PHP 7. As stated here: http://windows.php.net/download/. Initially I downloaded PHP 7.0 but this didn't play nicely with another module that I wanted to install, which was MongoDB.
When I looked into MongoDB I realised that there wasn't a driver for PHP 7.0 yet so the latest one I could get was PHP 5.6. This meant that I had to settle for an "experimental" 64-bit version of PHP. So I made the shift and everything was playing nice until I decided that I wanted to get Composer so that I could manager my PHP dependencies.
When I tried to intall Composer using the Windows installer it failed with an unknown exception and suggested I try from the command line to get a better error response. So I duly did and the error stated that the ssh2 module was not compatible with PHP 5.6.
That eventually brought me to ask the question on stackoverflow.
After some more digging into what versions of ssh2 there are I was brought to the following page: http://windows.php.net/downloads/pecl/releases/ssh2/0.12/
This told me that the latest version of PHP that was compatible with the SSH2 extension was PHP 5.5. So... it looks like the solution was to downgrade to version 5.5.
When I started looking for the new (old) version to download I came across this wonderful bundle package site: https://www.apachelounge.com/viewtopic.php?t=6123
From there I could download this version (https://phpdev.toolsforresearch.com/php-5.5.20-Win32-VC11-x64.zip) and it would contain all the modules that I needed in the correct version.
So, in conclusion, a little more up-front analysis into what versions play nice together would have helped or understanding that the Apache Lounge has all the versions that work together in a nice tidy bundle.
The thing is I have here a group of web developers and everyone works with WAMP in Windows. In there they work with a php extension called php_websockets. Basically in php.ini they just uncomment ;php_websockets.dll and voila.
On the other hand I work with Linux (CentOS 7 in this case), and there's no possible way I can find php_websockets in any php.ini or conf archives.
I know there are a lot of web sockets out there. But they insist me it must be this one.
Not sure if there are multiple "php websockets" projects out there; finding out the version number of the one they are using might help. Assuming it's this one: http://sourceforge.net/projects/phpwebsockets/, there are linux installation instructions at http://sourceforge.net/projects/phpwebsockets/files/:
LINUX INSTALLATION - Tested and works on the following systems:
- Fedora Core 17 PHP-5.4.9 x86_64
- Fedora Core 18 PHP-5.4.10 x86_64
- Fedora Core 18 PHP-5.4.12 x86_64
Build it from source - Simply unpack the files and at a shell prompt type these commands.
# phpize
# ./configure --enable-websockets
# make
# make install
# cp websockets.ini /etc/php.d/
If all went smoothly, websockets should be installed and working.
If you have any issues, please post them in the sourceforge ticket system
https://sourceforge.net/p/phpwebsockets/tickets/
NOTE: You will have to re-build if you update PHP
I am trying for the whole day but I cannot get my ImageMagick flying with XAMPP on a Win7 machine. I downloaded ImageMagick (for specs see below), downloaded the php_imagick.dll from the PECL website and added it to my php.ini.
ImageMagick runs smoothly in the command line. But as soon as I start my Apache (by the way, I tried with Windows reboot as well, for sure), I get one of the following error messages (I tried with different DDLs):
The procedure entry point "php_checkuid_ex" could not be located in the dynamic link library "php5ts.dll"
or
The procedure entry point "MagickGetImageGravity" could not be located in the dynamic link library "CORE_RL_wand_.dll",
(there has been a third error message where entry point was something with Draw...Alpha in CORE_RL_wand_.dll.)
Some specs:
Win7 (x64)
XAMPP, win32, v1.8.3-2, VC11
PHP v5.5.6, Compiler: MSVC11 (Visual C++ 2012)
ImageMagick-6.8.8-5-Q8-x86-dll
(I used to have the ImageMagick Q16/x64, but due to my exhausting research today I read that I should use the x86 variant as XAMPP/Apache are also running on 32bit - so I deinstalled the Q16 and installed the Q8. Unfortunately with no success.)
Anyone can help me figuring out which php_imagick.dll I need or any other idea what I have to modify so that this works?
I found the answer to basically the same question (and same tech spec). I simply had to download an older version of ImageMagick (ImageMagick-6.7.7-5-Q16-windows-dll).
(By following the linked answer above you can find a link to that version of ImageMagick and a working php_imagick.dll.)
I solve with these: https://github.com/WPN-XM/WPN-XM/issues/222
So I work with:
Win7 (x64)
XAMPP, win32, v3.2.1, VC11 with php 5.6.12
php_imagick-3.1.2-5.6-ts-vc11-x86
ImageMagick-6.9.2-0-Q16-x64-dll
I know that the Laravel 4 requirements are PHP >= 5.3.7 but my client must recent application server only has PHP 5.3.3. Yes, three years old version...
I need more arguments to explain the situation and find a solution with him (no move, upgrade or cloud hosting).
The questions are the following :
Can I make L4 run with PHP 5.3.3 ?
If not, why ?
If so, how and with what limitations ?
[EDIT] What I know about my client configuration is : Red Hat Enterprise Linux 6.3 on VMWare virtual machine with Apache 2.2 and PHP 5.3.3.
Laravel 4 requires PHP 5.3.7 due to using the bcrypt algorithm when hashing passwords, which received a huge bugfix at that version.
Have a look at this article for bringing the requirement of PHP for Laravel 4 down to 5.3.2: http://laravel.io/topic/39/laravel-4-easily-extended
EDIT: here is an archived version of the linked article, as the original appears to be down:
https://web.archive.org/web/20130805153640/http://laravel.io/topic/39/laravel-4-easily-extended
NOTE: some PHP versions of 5.3.3 on certain distros do have the bcrypt algorithm fix backported into them, such as RedHat. You can read on how you can test if the distro you are using is one of them here; if it is, your distro supports the fix, and in turn supports Laravel 4 out of the box.
I had an experience with a remote webhost that offers several versions of php, and somehow, was set to an older default version of php.
For example, I could not figure out why my migrations would not run - artisan commands failed for no apparent reason, when a nearly identical local setup worked. Come to find out that my root folder was set to 5.2 something. A quick chat session with the webhost guys, and they showed me how to fix. Presto- migrations work.
Much of the rest of my application worked, but the artisan functionality is a no-can-do-without for me. Hope that helps.
Also, the built-in php development web server is handy - starts with 5.4.
EDIT: Here is a little more ammo for you: another specific issue I encountered:
root#Grisbuntu:/home/ryan/MyApp6# php /usr/bin/composer.phar update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- zizaco/entrust dev-master requires php >=5.4.0 -> no matching package found.
...
root#Grisbuntu:/home/ryan/MyApp6# php -v
PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) (built: Mar 11 2013 14:31:48)
So there you have it: Entrust is one specific example of a package you cannot use without 5.4....
sudo add-apt-repository ppa:ondrej/php5
sudo apt-get update
sudo apt-get install php5
php -v
...PHP 5.4.15-1~precise+1 (cli) (built: May 13 2013 16:00:00)
composer update
...
I hope that helps someone!
UPDATE: July 2013, per php.net : Please Note: This will be the last regular release of the PHP 5.3 series. All users of PHP are encouraged to upgrade to PHP 5.4 or PHP 5.5. The PHP 5.3 series will receive only security fixes for the next year.