I have PHP 5.6 PHP 5.6.17-1+deb.sury.org~trusty+2 (cli) installed currently, on Mint 17.2 x64 (Cinnamon). If I try to install mit-scheme, I get:
sudo apt-get install mit-scheme
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
dbconfig-common libjs-codemirror libjs-jquery-cookie libjs-jquery-event-drag
libjs-jquery-metadata libjs-jquery-mousewheel libjs-jquery-tablesorter
libjs-jquery-ui php-gettext
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
libmcrypt4:i386 libmhash2:i386 libpq5:i386
Suggested packages:
libmcrypt-dev:i386 mcrypt:i386 mit-scheme-dbg:i386
The following packages will be REMOVED:
libmcrypt-dev libmcrypt4 mcrypt php5-mcrypt phpmyadmin
The following NEW packages will be installed:
libmcrypt4:i386 libmhash2:i386 libpq5:i386 mit-scheme:i386
0 upgraded, 4 newly installed, 5 to remove and 38 not upgraded.
Need to get 6,668 kB of archives.
After this operation, 5,040 kB disk space will be freed.
Seems the problem is between libmcrypt4 and libmcrypt4:i386. Is there not an x64 version of Scheme, or a way to keep those two mcrypt versions from interfering with each other? Best (of poor) options looks like installing Scheme in a 32bit virtual machine. Another option is compiling PHP from a 32 bit source, if that is possible on a 64bit machine. Anyone else run into this issue?
I actually ended up building mit-scheme from source outside my package manager on gentoo two years ago and it's still working. I would suggest you install mit-scheme from the source (https://www.gnu.org/software/mit-scheme/liarc-build.html) or update to jessie, as jessie includes an amd64 version, whereas wheezy does not. https://packages.debian.org/jessie/mit-scheme
So within wheezy the answer is not. However I know for sure you can compile 9.0.1 and later to a 64-bit target.
file /usr/local/bin/mit-scheme-x86-64
/usr/local/bin/mit-scheme-x86-64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.9, not stripped
Related
I use Oracle Linux with 64-bit Arm architecture in Oracle Cloud Ampere A1 Compute.
Since official Oracle Linux only support up to 7.4 and Remi repo also doesn't support aarch64 , how to install PHP 8 to aarch64/arm64 especially oracle Linux or other RHEL base Linux?
I don't want to build from source, but if it's the only way to install please give me steps by steps. Because I tried to build from the source but failed with so many errors (I tried with some different configs).
I think Oracle Ampere A1 is similar to AWS Graviton2, but I don't see any reference also how to install PHP 8 to AWS EC2 Graviton2. Is PHP8 really not supported on arm64?
To list available Module Streams for PHP:
$ dnf module list php
To install PHP 7.4 :
$ sudo dnf install #php:8.0
I'm currently trying to install PHP Tidy on a CentOS 7 server (I'm running PHP Version 5.4.16 if that helps as well), but am having problems with the install.
I've been running (as per the documentation)
yum install php-tidy
but get the following error:
No package php-tidy available.
Error: Nothing to do
I've found someone having the same problem here, and the answer is listed as
When I installed via CentOS tidy.x86_64 and php-tidy.x86_64 were installed but Red Hat could not find the php-tidy.x86_64 rpm and I had to add the EPEL repository, then I managed to install php-tidy.x86_64 and it worked
...but I'm not sure what to make of that.
I've also found via the official Tidy documentation:
On Redhat-ish linux, you must install both libtidy and libtidy-devel (PHP 5.x):
sudo yum install libtidy libtidy-devel
...however I also get the same "No package..." error.
My only lead is that it doesn't appear that any of the documentation has to do with CentOS 7 (I believe they use CentOS 6 or 5, or an older version of PHP) and some of the suggestions are that some systems require yum install php5-tidy instead. So hence my original question on if Tidy is supported on CentOS 7, or if there is something else I might be doing incorrectly.
Use the webtatic repo ... PHP 5.6 on CentOS/RHEL 7.1 and 6.7 via Yum
https://webtatic.com/packages/php56/
php56w-tidy
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 have a problem with the update on php 5.4.9 (i install it with the ppa "ppa:ondrej/php5")
Now i have the problem that i can't install libssh2-php (which is required on my project)
I found some .deb files, but it's only for 32-bit systems.
So when i'm trying to install libssh2-php i have a collision with "libssh2-php:i386" and i have the following dependiesmessage:
ucf:i386 libc6:i386 (>= 2.4) libssh2-1:i386 (>= 1.0) and phpapi-20090626+lfs:i386
System: Ubuntu Server 12.04 LTS x64 | PHP 5.4.9
I also got a warning on running "php -v"
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20100525/ssh2.so' - /usr/lib/php5/20100525/ssh2.so: cannot open shared object file: No such file or directory in Unknown on line 0
The problem is/was that the libssh2 is not aviable for PHP5.4.x AND a x64 system.
I have the same problem trying to use ondrej's ppa for ubuntu 10.04 LTS. It seams that he didn't include the sssh extension.
Apt-get tries to install the version from default package which runs into conflict (depends phpapi-20090626+lfs) with current installed version, isn't it?
Only my backup php cli script needs this extension to run. After trying to solve dependencies witout success, I switched to a shell_exec('ssh ...#...') solution as workaround.
I am only a developer with advanced admin knowledge, no apt-get or linux packaging admin professional. There maybe other solution to fix this via packaging management or maybe building the needed version from source?
EDIT:
There will be another nicer solution :-) you can use pecl to install / build the extension, here is what i have done:
$ sudo pecl install ssh2
Failed to download pecl/ssh2 within preferred state "stable", latest release is version 0.12, stability "beta", use "channel://pecl.php.net/ssh2-0.12" to install
install failed
$ sudo pecl install channel://pecl.php.net/ssh2-0.12
downloading ssh2-0.12.tgz ...
Starting to download ssh2-0.12.tgz (26,223 bytes)
[...]
Build process completed successfully
Installing '/usr/lib/php5/20100525+lfs/ssh2.so'
install ok: channel://pecl.php.net/ssh2-0.12
configuration option "php_ini" is not set to php.ini location
You should add "extension=ssh2.so" to php.ini
Afterwards I add extension=/usr/lib/php5/20100525+lfs/ssh2.so to php config.
Just do:
sudo aptitude purge php5-suhosin
It's described in detail here: bugs.debian.org
phpinfo() function shows that my PHP version (5.1.6) is installed --without-pear in the configure command section.
How do I install pear?
The Getting and installing the PEAR package manager page should help you : it gives informations on how to install the PEAR package manager, on both windows, Linux, and Mac.
Basically, if your Linux distribution comes with a PEAP package, you should install it.
For instance, on Ubuntu1, there is a php-pear package ; so, you'd use :
apt-get install php-pear
Else, if it doesn't, with a version of PHP >= 5.3, you should be able to use this :
$ wget http://pear.php.net/go-pear.phar
$ php go-pear.phar
With PHP 5.1, though, this is not going to work, as phar support has been added in PHP 5.3...
As a sidenote : PHP 5.1 is really outdated !
PHP 5.3 is more than one year and a half old ; even PHP 5.2 is not maintained anymore... maybe you should consider upgrading ?
1It seems you are running some kind of Redhat-based distribution, but I don't have one of those, so I cannot say if there is a PEAR package for it -- there is probably one, though.
--without-pear only means that the PEAR bits were not immediately created when PHP was compiled.
This usually happens when an operating system vendor that provides packages and wants to split off bits and pieces into their own individually installable parts.
Given the age of the PHP you're talking about, you're probably on RHEL or a derivative like CentOS. Check the package manager for a php-pear package.