I have installed Php 7.1.9 on a windows server 2012 machine, if I check the php info I can see that mcrypt is enabled but if I type in shell php -v I have this error:
Unable to load dynamic library 'C:/php/ext\php_mcrypt.dll' - The specified module could not be found.
In fact running a Laravel application I also get some exception related to it.
I have checked ext folder and there is no php_mcrypt.dll .
As you can see here mcrypt is deprecated in favour of OpenSSL. From the Deprecated features in PHP 7.1.x:
The mcrypt extension has been abandonware for nearly a decade now, and was also fairly complex to use. It has therefore been deprecated in favour of OpenSSL, where it will be removed from the core and into PECL in PHP 7.2.
you can use laravel's homestead, it will be a lot easier since it will handle your environment with all the necessary services required by laravel framework.
https://laravel.com/docs/5.5/homestead
Related
I use MAMP 5.5 (383) on my macOS Catalina (10.15.6) for general PHP related development. Some of my projects require LDAP connectivity for various reasons.
My process works well using MAMP, but recently I noticed that if I switch from whoever PHP version I have available in either app from PHP 7.2 to PHP 7.3 or above, all LDAP support stops; I get errors like this:
[30-Jul-2020 23:59:14 America/New_York] PHP Fatal error: Uncaught Error: Call to undefined function ldap_connect() in /Users/Jake/htdocs/ldap_test.php:3
Stack trace:
#0 {main}
And the only command in that file is simply a test ldap_connect() command.
In MAMP when I do a phpinfo() call, when it is running PHP 7.3.8 I see no LDAP references even in the configure command. But when I switch to PHP 7.2.21 I see --with-ldap in the configure command as well as this:
LDAP Support: enabled
RCS Version: $Id: 3839f871a91c293a52322c63329c68db23a0290a $
Total Links: 0/unlimited
API Version: 3001
Vendor Name: OpenLDAP
Vendor Version: 20428
Why is this?
I have tried to upgrade to MAMP 5.7 that has PHP 7.3 as well as PHP 7.4 but I get the same results; no LDAP support.
Has something happened in the way that OpenLDAP is supported in packages like this? I found this Homebrew related discussion which states the following and refers to this reported issue in an official PHP bug report:
“I can patch PHP 7.2 and older to use system LDAP again, but PHP 7.3 will require new symbols that only openldap exposes.”
Does this effectively mean that LDAP support in macOS is dead for PHP 7.3 and above unless there is a patch to PHP code or on the other side in the macOS implementation of OpenLDAP?
I use Ubuntu and CentOS as well and I can easily enable LDAP support via package installers there. But that’s little help when using MAMP for desktop development.
Looking for a solution that centers on the MAMP application and would like to avoid Homebrew or other setups where I am effectively building an M(acOS)AMP server from scratch on macOS.
Looks like this issue has been solved as of MAMP 6.3
LDAP support is back in the versions of PHP that come with MAMP 6.3 and higher.
Deciding to check a newer version of MAMP — since PHP 8 is looming and sticking with PHP 7.2 is no longer a real option — I downloaded MAMP 6.3 and it comes with PHP 7.4.12 and PHP 8.0.0 installed.
And without saying anything else… Both versions of PHP here have LDAP support baked in right out of the box! Confirmed by using a basic ldap_connect command as well as taking a few small apps I have developed around the block in these new versions of PHP and all works great!
So it seems like the PHP 7.3 cycles for MAMP had a weird “no-LDAP” blip. I recommend anyone wanting to move forward in their code, just download MAMP 6.3 and use PHP 7.4 at least and you should be solid.
The vendor version of LDAP contained in MAMP 6.3 is 20448 for anyone who needs to know that.
I am trying to install SPL_Types extension in my PHP 7.1.8 compiled from source.
I have tried with sudo pecl install SPL_Types and compiling the extension from source, but I get the following output:
https://mega.nz/#!WE5WjajQ!QyVxMYWrsUiDF6Gq09psYBpR5Y336v26PusnlBNd8bg
I know it's not cool to post links, but I was not able to put the hole output here.
This extension is outdated now and cannot be build with PHP 7.x. Latest version of this lib released at 2012 and supports only PHP 5.4. Native scalar type declarations support makes this extension mostly useless (maybe except for SplEnum).
With PHP 7.x many of internal PHP API was have significantly changed. As you can see in the attached output, source code of the extension uses dozens of outdated APIs (most of errors caused by missing macros, wrong data types, etc).
For the extension to be built with the new version, it must be updated accordingly: Upgrading PHP extensions from PHP5 to NG. If you are not familiar with C you can try to use unofficial fork or polyfill.
I have installed pthreads by the following http://php.net/manual/en/pthreads.installation.php
from
http://windows.php.net/downloads/pecl/releases/pthreads/
My php info :-
phpinfo();
PHP Version 5.6.30
Compiler : MSVC11 (Visual C++ 2012)
Architecture : x86
Thread Safety : enabled
But error still exists..
php -m output#
php -m PHP Warning: PHP Startup: pthreads: Unable t Module compiled
with module API=20121212 PHP compiled with module API=20131226 These
options need to match in Unknown on line 0 Warning: PHP Startup:
pthreads: Unable to ini Module compiled with module API=20121212 PHP
compiled with module API=20131226 These options need to match in
Unknown on line 0 [PHP Modules] bcmath bz2 calendar Core ctype curl
date dom ereg exif fileinfo filter ftp gd gettext hash iconv json
libxml mbstring mcrypt mhash mysql mysqli mysqlnd odbc
pthreads is not safe for web server environments (source) :-
I didn't disable pthreads in web server environments to annoy you; I
done it to keep you safe, and will not reverse that decision.
PHP and Apache do not provide the API required to make it properly
safe.
If I patched Apache and PHP tomorrow to include some additional hooks
in an effort to make it properly safe, you would never be able to make
it scale.
Threads are not a utility for an Apache worker mpm server, they are
part of the architecture of the software; Coming in and starting
additional threads inside that architecture is reckless and destroys
the ability of that architecture to scale and operate as it was
intended.
It never made sense to use pthreads inside Apache, I left it working
in previous versions in an attempt to lower the entry barrier
(everyone is comfortable with a web server). That was a mistake, my
mistake; Threading is not simple, when you try to make something
inherently complicated simple, you just make it stupid.
Allowing threads to be started inside Apache without the ability to
make either PHP or Apache properly aware of the change in architecture
was abusive, and extremely stupid.
another note , that apache2 by default running in mpm_prefork mode , which is means that -so to speak- " hey apache2 , please fork for me multi child processes , but with one thread for each"
Whilst Hassan Ahmed's reply explains why pthreads shouldn't be used in a web server environment, that is not the cause of the error you're receiving.
The problem is that the pthreads binary you have downloaded was not built for the PHP version you are using. This causes a mismatch between the pthreads' binary API and PHP's module API that it integrates into. Judging by your PHP version, you should be using the 2.0.10 release of pthreads, since that was the last stable release for PHP 5.6 version.
Note that support for pthreads for PHP 5.x versions is no longer maintained. If you would like the latest bug fixes and features, then use PHP 7.x and pthreads v3.
I'm looking to install the Amazon ElastiCache Memcached Cluster Client so I can take advantage of autodiscovery of cache nodes.
Unfortunately, it looks like they only available options are
Java
PHP 5.3 (64-bit Linux)
PHP 5.3 (32-bit Linux)
PHP 5.4 (64-bit Linux)
PHP 5.4 (32-bit Linux)
The version of PHP that is installed on my EC2 instance is PHP 5.5.3-1ubuntu2.1 (the default for Ubuntu).
Does anyone have any insight into whether or not the 5.4 package will work with PHP 5.5 or not? I did find one person looking for this on their forums but there doesn't seem to be a resolution there yet.
Only one way to find out, right? Well, the answer is no.
I followed the installation instructions and got this when I started up PHP:
PHP Warning: PHP Startup: memcached: Unable to initialize module
Module compiled with module API=20100525
PHP compiled with module API=20121212
These options need to match
in Unknown on line 0
I wanted to try using SAPRFC dll along with PHP to retrieve data from SAP server at our company, but after downloading the latest version (1.4.1) from http://sourceforge.net/projects/saprfc/files/
Then, I added the dll files (php_saprfc_528.dll and php_saprfc_530.dll) to PHP extensions folder, then I updated php.ini file. When I start Apache server, the following error message shows to me
PHP Startup: saprfc: Unable to initialize module
Module compiled with module API=20060613
PHP compiled with module API=20121212
These options need to match
Googling this issue, I found that that saprfc was compiled with another version of PHP not same as the one I'm using. I'm running PHP 5.5.9, so I started looking with saprfc dll file compatible with PHP 5.5, but I couldn't find.
Can anybody please provide the download for the php_saprfc.dll which will work with PHP 5.5, or what are the steps for compiling php_saprfc.dll that will make it compatible with PHP 5.5
Thanks
Compiled php module you can download here: https://sourceforge.net/projects/saprfcsapnwrfc/files/?source=navbar
Have you installed the RFC DLL on the system in question? At runtime the SAPRFC PHP module needs it - from the installation instructions (As you mentioned DLL I'm assuming you're using Windows):
For installation (from binary package):
PHP binaries (http://www.php.net/downloads.php)
librfc32.dll in Windows System directory (or SAPGUI installed)
You can obtain librfc32.dll from a system that has SAPGUI installed (check the Windows directory) or by installing the classic RFC SDK. For more information on that SDK, see note 27517 (SAP SMP login required).
Once you've done that and if the PHP module still doesn't work, then you can consider recompiling. See the instructions in that same installation guide for instructions. They do mention Visual C 6.0 though, which is rather old...