I've tried to build php7 with the command below:
./configure --prefix=/root/testphp --with-openssl --enable-zip --enable-mbstring --with-pdo-mysql --enable-static
make
make install
And then I try to run it on compile machine, it worked like this:
[root#guningvm ~]# /root/testphp/bin/php -v
PHP 7.3.4 (cli) (built: Apr 8 2019 11:25:09) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.4, Copyright (c) 1998-2018 Zend Technologies
But when I mount the dir /root/testphp on an alpine docker container:
docker run -itd --name "testforphp" -v /root/testphp/:/usr/local/php/ alpine:3.7
And run php command in the container with /usr/local/php/bin/php -v, it got wrong with sh: /usr/local/php/bin/php: not found
Could anyone tell me why it didn't work?I've taken a lot of time with this problem.Thanks a lot.
It's not entirely clear, but it seems you are building PHP on your local Linux machine (say, Ubuntu), and trying to run it on an Alpine container.
I'm also assuming you have good reasons for building PHP from source - otherwise, you could use the available PHP builds for Alpine.
Building on non-Alpine Linux and running the resulting executable on Alpine usually won't work, since Alpine Linux uses a special libc (Standard C library) implementation called musl libc. musl is not compatible with the GNU C Library - glibc, used by most other Linux distros, so for running native software on Alpine Linux, it must be built against that same, musl libc library.
The /usr/local/php/bin/php: not found error message is quite confusing, and assuming the file is present is likely to result from a dynamic linking failure. You could verify that using ldd /usr/local/php/bin/php.
Therefore, you'll have to link PHP against the musl C library for running on Alpine, and most preferably, on an Alpine machine.
I can think of the following options:
Build PHP on an Alpine container. I'm not sure whether the main development PHP branch supports this (for example, OpenJDK Java Alpine support is developed under seperate projects, named IcedTea and Portola), but it is well worth a try. I believe it is possible, since PHP builds are available for Alpine - try following their build recipe, if you encounter difficulties. This is the best option, in my opinion.
Keep building PHP on your non-Alpine Linux machine, but link it against the musl libc binary (usually available through packages), instead of glibc. This may be more difficult to achieve, and more prone to issues, so less recommended.
Run your built PHP on a glibc-enabled Alpine container. This is a fairly simple procedure. However, this option is probably not a viable one, since your PHP would still be non compatible to vanilla Alpine, and can't be used by PHP Alpine users out-of-the-box. Plus, adding glibc to the container has several MB overhead, which conflicts with your goal for minimal size.
Devils advocate answer:
If your host os was, say, fedora 30 and your container was based on a fedora 30 image, this would work fine.
But then again, we go back to my initial comment about how this isn't the way we use containers.
Related
Environment:os and apache and php and mariadb version.
uname -a
Linux MiWiFi-R3-srv 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux
sudo apachectl -v
Server version: Apache/2.4.25 (Debian)
Server built: 2019-10-13T15:43:54
php -v
PHP 7.0.33-0+deb9u6 (cli) (built: Oct 24 2019 18:50:20) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.33-0+deb9u6, Copyright (c) 1999-2017, by Zend Technologies
Login mariadb with password and input status:
Server: MariaDB
Server version: 10.1.41-MariaDB-0+deb9u1 Debian 9.9
Check php-mysql:
sudo dpkg -l php-mysql
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii php-mysql 1:7.0+49 all MySQL module for PHP [default]
Get the mysql.so library:
sudo find / -name "*mysql.so"
/usr/lib/php/20151012/pdo_mysql.so
Chekc all modules which contain mysql:
php -m |grep mysql
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/php_pdo_mysql.so' - /usr/lib/php/20151012/php_pdo_mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0
mysqli
mysqlnd
pdo_mysql
sudo vim /etc/php/7.0/fpm/php.ini
Rewrite
; ... or under UNIX:
;
;extension=mysql.so
as
extension=mysqli.so
or
extension=mysqlnd.so
or
extension=pdo_mysql.so
Restart apache2 and mariadb database,the issue remains ,none of the three format can work,how to fix then?
pdo_mysql is not the same as mysql.so. The old mysql extension was removed in PHP 7.0. The supported extension is now only mysqli.
From there on it depends on what the software is expecting to find - if it needs the old mysql library, then you're going to have to use a shim or an older PHP version (i.e. anything before PHP 7, such as PHP 5.6).
You can use the php7-mysql-shim library or the mysql-shim library (be aware, this might incur a small performance penalty) to make a transparent mapping available that dispatches any calls to the old mysql library to the still supported mysqli library. As long as you've installed php7-mysql-shim through composer and your project uses composer, it should be loaded automagically.
A third option is to run the original code through the mysql-to-mysqli rector configuration, but if this is not your own code, that will be hard to maintain in the future.
The .so file that can't be loaded might be because of permission issue. Make sure to ls -al that file and correct any ownership or permission issues (chmod og+r <filename>, probably).
Remove php and related packages.
sudo apt-get autoremove php7*
sudo find /etc -name "*php*" |xargs rm -rf
sudo apt purge `dpkg -l | grep php| awk '{print $2}' |tr "\n" " "`
Check.
dpkg -l | grep php7.0
Install.
sudo apt-get install php php-mysql
At last my issue solved.
MatsLindh is right, mysql is deprecated from php 7, it seems that you have deployed old php5 code on the server that is why you received this error, now you can do two things
either install php5.6 and select the version for that website folder depending on which hosting you have and restart the server
or you can upgrade the code to php 7+ either yourself or by using tools which I do not know if it works perfectly, recently I came across this
Rector Tool for upgrading php legacy code
We were down the same path in previous months and and we updated mysql code to mysqli and also updated the classes declarations and added the necessary checking, fixed the error handling and we were able to run the legacy app on the php 7 successfully.
Sometime due to complicated development, it is not possible to upgrade in an instant and it is also not possible to start from the scratch either because of the business logic introduced over the years so changes can only be introduced with baby steps, I can say this because we handle our high traffic ecommerce site.
As others have stated, though without a source, the mysql extension (ext/mysql) was deprecated in 5.5 (per RFC: ext/mysql deprecation) and removed in 7.0 (per RFC: Remove deprecated functionality in PHP 7).
(This is the git commit that actually removed ext/mysql from PHP, as linked to from the removal RFC - this link was added by the RFC author [nikic])
This is also mentioned all throughout the ext/mysql manual on php.net, though it doesn't link to any other notes concerning the deprecation and subsequent removal.
If you view the backwards-incompatible changes page for 7.0 then it further mentions that all mysql extension functions were removed, and provides a link to help in choosing a new MySQL API. This provides the support and path necessary for moving on from ext/mysql.
Avoid using a quick fix that will make your application support the old php-mysql driver. There is a reason that it was removed from php.
You can use the successor of php-mysql which is the MySQLi driver, the name MySQLi actually means MySQL-improvedand as you can understand is an improved version of the MySQL driver that gives the developer more benefits.
You may also use the PHP Data Objects (PDO), an extension that defines a lightweight, consistent interface for accessing databases (MySQL is one of them) in PHP.
This would mean that you would have to re-write pieces of code related with database handled information. If you wrote a class for it then you only need to re-write that class only. If all the MySQL related functions are written in all your application then you have a lot of work.
DO NOT USE THE OLD MySQL EXTENSION OR SOMETHING POINTING THAT BY USING A QUICK FIX.
Do some further reading of your own to judge for yourself what would be the best practice for this situation, MySQLi Wiki, Introduction to PDO, MySQLi Overview.
The First thing that you need to check for this issue is PHP version compatibility with the existing CMS Version.
In most of the cases the error due to that only.
If you are using the domain hosting and have a various site in that, you can also switch the PHP version in one sub domain only by this Htaccess file.
Like this - FcgidWrapper "/home/httpd/cgi-bin/php53-fcgi-starter.fcgi" .php
Thnak you!
Good day,
Just to clarify, I'm asking about macOS Server, the application published by Apple. I'm not referring to the system's PHP version.
I've looked everywhere, Google, SO, forums, for quite some time and haven't found a solution.
I'm unable to upgrade my PHP version for macOS Server no matter what I try. There's just simply no documentation.
I've updated the app from the App Store, I've upgraded my PHP version on my Mac, and I've changed the PATH to reflect the new PHP install, and when I do php -v in Terminal, it shows the correct version I want.
However, macOS Server seems complete unaffected by it. I tried looking around everywhere possible, but I don't see a separate install of PHP for Server, and I looked in the config files, everywhere, but can't see where and which PHP it's using.
Any help?
EDIT: I just realised that it's a whole application which many parts actively use PHP, and upgrading it on my own may break those things, but I'm willing to give it a shot, if it's at all possible. I mean, the worst that can happen is for me to delete and re-install Server, right?
Installing php on macOS
Honestly, you sound like you know more about this than is evident in the question. So you probably know a lot of this, but I wanted to be as complete as I can, from my experience, since these responses remain for others who may locate them in the future and find the information useful. If I have left anything out, I hope someone will point it out for me so I can learn a bit more along the way.
Back in the day, then thunder gods ruled the world:
php has come bundled standard on Macs since Mac OS X version 10.0.0, as you can read about here. The first version of Mac OS X Server (1.0) was a hybrid of OPENSTEP from Steve Jobs' NeXT Computer and Mac OS 8.5.1 released in 1999.
Starting with Mac OS X 10.7 (Lion) Mac OS X and Mac OS X Server have been combined into one operating system package and the macOS Server is an add-on package available through the App Store. This means that you can't really worry very much about ruining anything too important.
You can't always get what you want ...
A lot of the value in this response will depend on what you use the Server package for. If you only use the web server for a development environment, it can easily be replaced with any version of the typical LAMP (linux-apache-mysql-php) style environment.
For macOS, this means upgrade apache, install php, and install MySQL if you cannot use SQLite that comes bundled with macOS. Here is one of the many great tutorials available online. (no affiliation) It can get complicated ...
Another option that is popular, but that I haven't used myself, is the non-profit XAMPP. They are focused on making it simpler to setup php development, Wordpress, Drupal, e-commerce, and popular open source apps.
When you're a stranger ...
If you are using some of the more esoteric apps that came with the server package, you will have to upgrade them separately. But since you are asking about php and the server recognizing it, I'm assuming you are talking about the web server and that you are using something like this to see what php version apache is finding:
<?php phpinfo(); ?>
Most likely, what you are saying is that the command line php version shows correct versions and settings, but the web page version served by apache shows the old version. Is that right?
Version and File Locations:
I'm not sure if you have checked for this, but the first thing I would do is find out for sure what the path is and what version I am using. This also gives me a quick direct link to the ini file so I can go break stuff faster. Here are my results (screenshot at the end) using php --version and php --ini:
$ which php
/usr/local/bin/php
$ php --version
PHP 7.3.6 (cli) (built: May 31 2019 23:38:25) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.6, Copyright (c) 1998-2018 Zend Technologies
with Xdebug v2.7.0, Copyright (c) 2002-2019, by Derick Rethans
with Zend OPcache v7.3.6, Copyright (c) 1999-2018, by Zend Technologies
$ php --ini
Configuration File (php.ini) Path: /usr/local/etc/php/7.3
Loaded Configuration File: /usr/local/etc/php/7.3/php.ini
Scan for additional .ini files in: /usr/local/etc/php/7.3/conf.d
Additional .ini files parsed: /usr/local/etc/php/7.3/conf.d/ext-opcache.ini
A touch too much:
Using php -i will output an enormous amount of information. It is many pages ... more than you would ever want. If you are looking for specifics, you can grep it for whatever you like: php -i | grep ini or php -i | grep -- '--with' to look for options.
Hiding in plain sight:
Most likely you are checking, testing, and upgrading the wrong installation of php or apache. macOS is infamous for having standard versions of many programs and it will likely break something if you upgrade the 'system' version of any of them.
Ruby and Python are the most common ones to cause problems for me. I have never had any issue with php, but there and many workarounds available for many programs (e.g. coreutils for gnu).
Homebrew!
The easiest way I have found is to use Homebrew to install a separate version that you can manage and upgrade as you like and link it somewhere early in your path so it is always the first version found.
$ brew install php
It does everything for you and keeps it updated. It also allows php to always be running as a service using brew services start php. This reduces startup time and prevents some multiple version issues. A list of all brew services and status info is, as you might expect, found with brew services list. If you update any config or ini files, you should restart php (and apache) with brew services restart php. You can also still use launchctl and apachectl if you choose.
Apache!
The other handy thing about homebrew is that you can use it to install and manage apache2, also. Try this:
$ brew install httpd
$ brew services start httpd
$ httpd
Non-alcoholic recipe:
If you prefer to abstain and not use homebrew, you can install any version you wish from php.net and make a link in a directory early in your PATH. Patches and upgrades are regular and everything is extremely professional and well (over?) documented.
Download a php binary, check it with the provided signatures, and link it somewhere on your path: ln -s /path/to/new/php ~/bin/php or somewhere else if you don't use your /home/bin. Homebrew puts the link in /usr/local/bin by default.
No matter which method you choose, after you install the programs you will definitely have to adjust a few settings. There are several great posts online about this. This one is a multi-part series and is updated for Mojave. The main information to get you started should be available as shown in the screenshot below.
I'm currently using Raspbian Wheezy 7.0 right now. Since PHP 5.6 is not available on the apt repositories for wheezy, I decided to build it from source. The build worked perfectly, I didn't receive any errors from it.
So when I used php -v it gave me the following output.
PHP 5.6.10 (cli) (built: Sep 18 2016 09:23:21)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
Ok, I thought. Perfect, everything is updated like it should be.
Here's where the problem comes in. For some reason, when I use phpinfo() on my apache2 server. It says that I'm still on version 5.4.45.
My first guess was that the module apache was using libphp5.so located in /usr/lib/apache2/modules/ was out of date. But, I have no idea where the libphp5.so module is for the new php version that I just installed is.
It'd be great if anyone could help me with this or point me in the right direction. I'm using Apache version 2.2.
As you can see from your console, php -v is the CLI binary. When building PHP you can build many different binaries for different SAPIs (Server APIs), one of them being CLI. Apache2 Handler or mod_php would be another one. In order to build your PHP as an Apache httpd module you need to make sure you include the --with-apxs2 configuration option when compiling from source. This means running ./configure --with-apxs2 before you make; make install; the binary. You then need to make sure to load the newly built libphp5.so or mod_php.so (however you built it) to the appropriate directly and load it from your Apaache httpd config. Where your newly compiled binaries are stored, depends on your compile time configuration options and environment, but typically they are located in $PREFIX/$HOME/bin. So for example, if you compiled --with-prefix=/usr you might get /usr/php/bin/libphp5.so, but typically the binary is moved for you by make install. You do need to make sure you restart httpd for the newly built binary to be loaded.
See the PHP manual on installation for more details.
Documenting my struggles to help others and hopefully get some feedback on how I could have done it better.
The command pecl install pthreads fails due to the php installed on my ubuntu 13.04 box not having zts configured.
Options:
1) The ubuntu respository does not have a php package with zts enabled. As of this post, ubuntu only has php 5.4.9 in it's repository (Released: 22 Nov 2012). It is possible to compile a php version from source - which I eventually did (see below), but..
2) I .. ALSO .. wanted to use phpfarm for the ability to run different versions of PHP on my local setup. On github, there is Christian Weiske's original contribution here (phpfarm) and a fork that he has contributed to, by François Poirotte - also called phpfarm. Francois' fork has a few more options to configure ('post-install customization') but I was not able to make that work with a PECL extension. I'm curious to know if misunderstood how to do that, because it looks to me that it just simply does not take PECL commands.
3). Prior to recompiling php from source, I loaded phpfarm (tried both versions), enabled php-fpm (FastCGI) and was able to get my apache2 server to use a phpfarm version (5.5.10) which showed up in a phpinfo() output. But the php-cli always showed the original php version (5.4.9) in the cli (run: php -v). Running (run: php -i | grep php.ini) showed /etc/php5/cli but I had previously removed php5 and aptitude show php5 returned a state of 'not installed.' I even renamed the /etc/php5 directory to see if I could force the system to use the phpfarm php version. Obviously, this is incorrect thinking and I went on to simply compile php 5.6 from source. But, is there something more to do to get a phpfarm php to be used in the cli? I read that the cli loads it's configuration file on a per command basis, unlike the apache2. If I could have run the 5.5.10 version (configured with zts) then I could have then done pecl install pthreads and then re-complied the phpfarm 5.5.10 version with pthreads enabled. Although it appears I will be able to run various versions of php in the apache server, will I ever be able to switch-phpfarm to another version and see it working in the php-cli? Also, I was uncertain on where I could have loaded a pthreads file for the phpfarm compile process to find and use it; could I have done it that way?
4) This stackoverflow post, essentially posted by Joe Watkins - the developer of pThreads is a perfect how-to on getting pThreads installed on a Ubuntu system that has had php configured with zts (Zend Thread Safety). (Thanks Joe!)
A nice tutorial on using phpfarm configured with fast-cgi and the apache server to help run websites under different php configurations.
So what gives with php, php-cli and the phpfarm?
I'm not sure about phpfarm, but do know of another solution ...
Multi
A tool for maintaining multiple installations of PHP in multiple configurations
https://github.com/datingvip/multi
This is a bit more user orientated, will allow you to build many configurations and versions of php, any tagged release of php, and any patched version from any fork of php-src.
In addition, because I wrote it, it will install pthreads for you.
git clone https://github.com/datingvip/multi
cd multi
VERSION=5.5.10 DBG=no-debug ZTS=zts ./php.multi
The above commands will yield an installation of PHP (in one suitable configuration, of one version) in /opt/php.
Look at php.defaults for configuration options and adjust before building
Should configuration fail on, for example, something related to a library like libxml2, it will usually be the case that
sudo apt-get install library-dev
Where library is replaced with the name of the library holding up the build, will fix the problem for you. If it does not, a quick google should get you going again.
Once the build is complete
source /path/to/multi/php.env 5.5.10
Note: multi will always install pthreads for any zts version automatically
I hope that gets you somewhere ...
First off I am not sure if I am at the right place or better at serverfault.
I am working on a PHP project and need access to an Oracle 10g DB. The server I am using is provided and maintained from a 3rd party. Lets call them ABC. I have only a restricted user. So everytime I need something I have to ask them to install it. This worked fine until now.
The server is a RedHat server and ABC is only allowed to install software from the official repositories. We were able to install the Oracle Instant Client but did not find the PHP libraries within the repository.
Our second try was to find a rpm-package containing the OCI8 library which is compatible with the installed software. Unfortunatly we only found a version which needs a newer PHP version which, you guessed it, is not part of the official repository.
Okay, I checken php.net and they told me that I would be able to compile it myself as a shared library. Neat, that would be enough. The problem here is that i am not able to run the phpize command as locking failes (in terms of blocks) the process. The root-User from ABC would be able to do it, but they are not allowed to compile anything.
So here I am asking you guys if there is a way to download the files and use it as a shared library without installing, compiling or whetever. The server is a 64bit RedHat Enterprise 6:
Linux [SERVERNAME] 2.6.32-358.11.1.el6.x86_64 #1 SMP Wed May 15 10:48:38 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
Any help is highly appreciated!
Thanks,
Alex
I found a way:
1. Set a proxy for pear:
pear config-set http_proxy http://[proxy]:[port]
2. Get sudo rights to use pecl
3. Install:
sudo pecl install oci8