I'm using a Mac with OS X Mavericks, and running php scripts within MAMP. Some of the php scripts I'm running require the use of pthreads.
Can anyone provide step-by-step instructions on installing or enabling pthreads on a Mac?
I have Googled extensively and have found little-to-no documentation on this. All I have found is that I may or may not have to recompile php from source, or maybe just add a couple flags to php.ini, or maybe I can just use pecl, etc. In terminal, I tried pecl install pthreads and received this error:
Cannot install, php_dir for channel "pecl.php.net" is not writeable by the current user
I'm pretty much lost at this point. I want to avoid switching to my Windows machine with WAMP if possible.
I'm not a Mac user, however the build process is the same for Mac and unix, so I can help you with that.
To configure your current installation:
Cannot install, php_dir for channel "pecl.php.net" is not writeable by the current user
This is the reason pecl install failure, maybe check the configuration for php_dir.
You can ascertain the value of the setting with:
pecl config-get php_dir
I am unfamiliar with MAMP, but it is probably the case that you do not have a Thread Safe build of PHP.
You can ascertain this with:
php -i | grep Thread
You should expect:
Thread Safety => enabled
If you have Thread Safety enabled, it should be the case that fixing the permissions on php_dir will fix your problem.
If you do not, you will have to rebuild, or install from another source, a Thread Safe build of PHP.
Building Yourself
The last option is to build yourself, since this means you will miss out on updates provided by upstream, though I'm not familiar enough to know for sure if there is a well maintained thread safe build, I will assume that there is.
To build yourself you will need to overwrite your current installation with a new one, download the sources to PHP for your desired version (5.5+ recommended, latest stable, all the time is best).
Enabled Extensions
You will want to ascertain which extensions are enabled for your current build and decide which you want to enable in your new build.
To ascertain which extensions are enabled:
php -m
Make a note of these:
php -m > enabled-extensions
Configuring the Build
To configure the build to be Thread Safe use the following configure option:
--enable-maintainer-zts
You will want to set the prefix of the new installation to match the old with:
--prefix=/old/prefix
If your current php binary is at /usr/local/bin/php, then the prefix is /usr/local.
If your current php binary is at /usr/bin/php, then the prefix is /usr.
You will also want to match your current builds configuration directory and scan directory settings:
--with-config-file-path=/old/config/path
If your current php.ini is at /usr/lib/php.ini, then the path is /usr/lib
If your current php.ini is at /etc/php.ini, then the path is /etc
If you are using scan directories at startup, for example, you have the directory /etc/php.d
--with-config-file-scan-dir=/etc/php.d
If your current scan directory is /etc/php.d, then the dir is /etc/php.d
To configure extensions, referencing the list you made at the beginning, use the command:
./configure --help
To figure out the switches enable your chosen extensions. If there are extensions in the list that are in pecl, you can install those after the build is complete with the pecl command.
Generally:
--enable-extname: no dependencies on external libraries
--with-extname: dependent on external libraries
Making the Build
After configure we have to run make, if you have multiple processors or cores, you might want to use multiple jobs:
make -j8
Will allow make to run in parallel (maximum of 8 jobs), this speeds up builds considerably. Use as many jobs as you have cores.
During make, if a failure occurs it will be obvious what the failure relates to, if you can spot the name of a library (usually the name of the extension that causes failure is helpful), then you can usually resolve the error by installing the development package for the library that caused the failure.
A development package contains headers and or static libraries, it is usually the case that package maintainers omit this stuff from normal packages to save weight, so you can have the libxml2 package installed but not have headers.
Installing the Build
When make completes you will have your build ready for installation, make sure you have permissions for the prefix and execute
make install
Pecl Extensions
You should now be able to install the PECL extensions that you require with
pecl install extname
pthreads
You can now install with PECL or from github:
pecl install pthreads
Related
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 ...
I always get this weird questions about how stuff works behind the scenes. I know how to compile php from source, and I know that if you compile it from source and forget to add a module/library you need to re-compile php to add it. However, if you install php lets say using yum, and then you want to add another extension, you just need to install that extension. For example, today I was working on a recently installed Fedora 18 machine, and php was missing the DOM library, which is weird, since that library is enabled by default. It seems like yum installs php with that extension disabled. Anyway, since it was missing, I had to do this:
sudo yum install php-xml
And that solved the problem, but it made me wonder, how is the installation process in this case? Is php re compiled? and if so, how does it remember all the other extensions that may have been added before? Or is the xml extension installed separately and somehow linked into php?
I haven't found any info about this, and I'm really curious as to how it works.
When you install php extension packages using a package manager like yum or apt-get, the repositories have the already compiled so extensions for the version of php that came with the system. For example, if you're on Ubuntu 12.04, and you do a apt-get install php-mysqlnd, it fetches the deb package from the repository which contains the pre-compiled mysqlnd.so and a default mysqlnd.ini. This works because the deb package has the compiled version according to the default dependencies that are installed for the 12.04 release. If some dependencies are missing, the precompiled deb packages are fetched for the same, thus eliminating the need for configuration and make. This make it a lot faster and easier. Almost plug and play!
You can build extensions separately, you don't have to rebuild your php every time you need to add a new extension, you just need to define the extensions that needs to be loaded under [extensions] in your php.ini.
When your building php you can specify which extensions you need to be statically (included) in the php binary vs which once you want as a shared library.
configure --enable-http=static --with-openssl=shared
// http extension will be included in PHP
// openssl extension will be compiled as separate DLL
Yum connects to repositories of pre-compiled rpm's. Yum will download the rpm and its dependencies and install them.
Yum will use different repositories for different OS's. For example Fedora 18 has a different repostitory of pre-compiled rpms then Fedora 17 would have.
Yum is just a glorified dependency management system
I'm trying to install a PECL package on Linux, but the installer never gets past the configure stage.
My hosting provider mounted a file system at /var/tmp that prevents files from executing, and that's causing this error:
root#host [/usr/local/apache/conf/includes]# pecl install pdo
downloading PDO-1.0.3.tgz ...
Starting to download PDO-1.0.3.tgz (52,613 bytes)
.............done: 52,613 bytes
12 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
building in /var/tmp/pear-build-root/PDO-1.0.3
running: /root/tmp/pear/PDO/configure
checking for egrep... grep -E
checking for a sed that does not truncate output... /bin/sed
checking for cc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
ERROR: `/root/tmp/pear/PDO/configure' failed
I'm 99% sure the problem is that you can't execute files in /var/tmp (I copied an executable file over here and tried it to verify). I'm sure I can get PECL to complete if I have it do its build work somewhere else, but I can't find the appropriate configuration setting.
How do you tell PECL to build in a non-default folder?
Whoa, why are you installing PDO from PECL? PDO has been built in to PHP since 5.1. Are you running 5.0?
If you're running 5.1 or higher and are missing PDO, chances are that:
Your copy of PHP was compiled without it, and must be recompiled; or
Your copy of PHP was installed from your OS's repository without the PDO module
If 1, you'll need to either recompile PHP from scratch, or compile just the shared module and copy it to the correct location.
If 2, you'll just need to install your OS's PDO extension. Under RHEL and CentOS, try yum search php-pdo. I don't know the proper syntax for calling the package installer for other distros, but the package will almost certainly include the string "php-pdo". (Tip: If you got your PHP from your OS, they also might provide common PECL packages. Try searching for "pecl" in their repositories.)
Finally, if you're running 5.0... for the sake of all that is good in this world, upgrade! Read through the upgrade notes in the PHP manual first, just in case you're using old behavior by accident.
(Also, to reconfigure pecl, try pecl config-show to see what settings are available, followed by a pecl config-set ... to change a setting. Do not try to install the PDO extension for a version of PHP newer than 5.0.x, it will break. There's even a big fat box at the top of the PDO page on the PECL site.)
The answers above may help the user, but not those that run into the "noexec" problem with the /tmp dir.
Here's how to pecl install [program] when it fails with "configure error cannot run c compiled programs" because you cannot execute stuff in the /tmp directory:
First remount the /tmp directory with the exec option turned on:
mount -o,remount,rw,exec /tmp
Second, install your pecl extention:
pecl install [extention name]
Third, once you are done you should set it back to 'noexec' using:
mount -o,remount,rw,noexec /tmp
In my case /tmp is noexec, /var is executable.
main10:~# mv /tmp/pear /var/tmp
main10:~# ln -s /var/tmp/pear /tmp/pear
It solved the problem.
I am running Fedora Core 10 with php 5.2.9 without ldap. Now i want to remove current php installation and recompile the latest version of php with ldap and install it.
How to do this?
Basically, download the sources from the PHP website. Then, from a terminal, type './configure --prefix=/usr/local/my_php_version'
In the output, checks if it recognize your LDAP installation (and also the Apache one). If not, take a look at the configuration options to learn how to specify the paths. Something like '--with-openldap', '--with apxs', etc.
You should also take a look at the configuration options to active the features you need.
Once you're done, type 'make', then 'sudo make install'.
Also take a look at the official install documentation: http://www.php.net/manual/en/install.unix.php
Instead of re-compiling the PHP, you can add the LDAP support to the PHP you have installed.
You can install a variety of libraries and modules without recompiling PHP. To see the libraries that are available, you can execute
yum search php-
To install LDAP for your PHP, you can execute
yum install php-ldap
If you have PHP as an Apache module, you must restart the httpd to activate the changes
service httpd restart
I'm using yum on CentOS 5.1 - I hand-compiled PHP 5.2.8 from source, but have other packages installed using yum. I need to install a PHP extension via pecl, and it requires phpize to be installed as well. However, doing the following yields a dependency error:
sudo yum install php-devel
Error: Missing Dependency: php = 5.1.6-20.el5_2.1 is needed by package php-devel
Since I actually have a newer version of PHP already installed, how can I force yum to ignore this? Do I need to hand-compile pecl/phpize from source? I admittedly never had a problem before, it only seems to be because of a combo of compiles and yum installs.
Any thoughts?
Thanks,
Kyle
In general:
If you build it yourself, it goes into /usr/local, and is only accessible to other things in /usr/local.
If you install from RPM/Yum, it goes into /usr, and is accessible to /usr and /usr/local.
So, if you want to install PHP tools using home-compiled PHP, install them into /usr/local as well: typically, with GNU-type software, that'd be something like:
./configure --prefix=/usr/local && make && sudo make install
or
make prefix=/usr/local all && sudo make prefix=/usr/local install
…although most software should default to /usr/local unless you override its prefix setting.
If you want to “hand-build” packages that are based upon RPM's, you can use
yumdownloader --source WHATEVER-PACKAGE
rpm -i WHATEVER-PACKAGE.rpm
rpmbuild -bp ~/rpm/SPECS/WHATEVER-PACKAGE.spec
(your path equivalent to ~/rpm may vary; rpmbuild --showrc will tell you where)
This downloads the .src.rpm package, which contains the upstream (original author's) source (usually a tarball) as well as OS-specific patches; installs the sources into ~/rpm (or your rpmbuild prefix); and then unpacks the sources and applies the patches into ~/rpm/BUILD/WHATEVER-PACKAGE/
From there, you can do the configure/make steps yourself, with the /usr/local prefix
Of course, just installing from RPM's is far easier :-)
yum doesn't know anything about your hand-compiled php version. You can either bypass RPM's dependency resolution by installing the package using rpm --nodeps and hope it works.
Or install the php version you compiled yourself in another directory so it can coexist with the old version from yum, so everyone is happy (not sure if that's possible, I guess it depends on whether your apps use a hardcoded path to php or not).
Or, if you are lucky, a third-party repository like EPEL or RPMForge might have a newer php package, so you don't have to compile your own.
As a rule of thumb, it's better to have one package management in the system, so you'll be better off packaging everything in RPMS and managing it via yum. It will save you lots of time in the long run.
If you absolutely want to have something (fe PHP) compiler from sources by hand, use stow/checkinstall/... or any other solution which would enable you to do rudimentary package management for source-compiled stuff.
Regerding your question, you could try to override dependency checking by downloading RPM of the required package an doing "rpm -i --force file.rpm", since yum does not have any option for forced installations