Gmp PHP extension - MAMP PRO - php

I've looked around several other questions like this one, guide like this or this but I still had no luck.
Here's what i've done so far:
Downloaded gmp with brew using brew install autoconf gmp
Downloaded PHP (i'm using version 7.3.24) from source
Copied Gmp directory to /Applications/MAMP/bin/php/php7.3.24/include/php/ext
Entered that dir and launched phpize
Launched ./configure --with-php-config=/Applications/MAMP/bin/php/php7.3.24/bin/php-config
Launched make
Launched make install
So far, so good. No errors, all seems fine but if i look at this point to my cli php -m (or php -i) there's no gmp extension loaded. So i went to my cli php.ini file and my web php.ini file and manually added extension=gmp.so (the file exist in this path /Applications/MAMP/bin/php/php7.3.24/include/php/ext/gmp/modules/gmp.so).
I even tried to specify the full path, but still no luck. Neither my cli or my phpinfo(); shows GMP enabled. I'm kinda confused atm and can't think about anything else.
What am I missing? Obviously, I restarted MAMP PRO like a dozen times, even my mac itself.
MacOs version: 11.4 Big Sur on iMac 24' M1
MAMP PRO Version: 6.3.1
PHP Version used: 7.3.24
Update 08/07/21
I updated MAMP PRO and it installed PHP version 7.3.27 so i went all over it again, download php from source https://github.com/php/php-src/releases?after=php-8.0.4RC1, copied ext/gmp into
/Applications/MAMP/bin/php/php7.3.27/include/php/ext, launched /Applications/MAMP/bin/php/php7.3.27/bin/phpize, ./configure --with-php-config=/Applications/MAMP/bin/php/php7.3.27/bin/php-config, make and make install. No errors.
Output of make install is:
Installing shared extensions: /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/
Installing header files: /Applications/MAMP/bin/php/php7.3.27/include/php/
shtool:install:Warning: source and destination are the same - skipped
I added extension=gmp.so to php.ini via MAMP interface, file, edit template -> php -> php7.3.27. Restarted MAMP and nothing new on phpinfo();
Update 12/07/21
As per Hakre request i've run the following command into cli and this is the result:
[~]$ php -n -d extension=gmp.so -i
PHP Warning: PHP Startup: Unable to load dynamic library 'gmp.so' (tried: /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so (dlopen(/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so, 9): no suitable image found. Did find:
/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so: mach-o, but wrong architecture
/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so: mach-o, but wrong architecture), /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so.so (dlopen(/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so.so, 9): image not found)) in Unknown on line 0
phpinfo()
PHP Version => 7.3.27
which is quite interesting if you look at this img
The extension actually exists
For Raptor:
This is the output of the commands you've asked.
[~]$ which php
/Applications/MAMP/bin/php/php7.3.27/bin/php
[~]$ php --ini | grep "Loaded Configuration File"
Loaded Configuration File: /Applications/MAMP/bin/php/php7.3.27/conf/php.ini
[~]$ php --version
PHP 7.3.27 (cli) (built: Mar 16 2021 12:04:51) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.27, Copyright (c) 1998-2018 Zend Technologies
[~]$
Ofc there are multiple php's installed since MAMP alone fill it with like 4-5 version + there's the default one from MacOSx which i've overwrote with .zshrc bash profile
export PATH=/Applications/MAMP/bin/php/php7.3.27/bin:$PATH
That line is from my .zshrc
Could the issue be related to the new M1 chip? I'm using a new iMac bought just at the end of June2021.
Maybe is this related?
For Haridarshan:
Let me start saying that i tried to use .configure with no additional params, then i tried with CC="gcc -arch i386" CXX="g++ -arch i386" and even with CC="gcc -arch arm64" CXX="g++ -arch arm64" (i found arm64 in configure.log). None of them produced a valid .so, if i didn't miss any other info from the command line.
About the test u've asked me to make, this is the result:
[~]$ file /Applications/MAMP/bin/php/php7.3.27/bin/php
/Applications/MAMP/bin/php/php7.3.27/bin/php: Mach-O 64-bit executable x86_64

There can be many reasons why a PHP extension is not loaded, but it is not always easy to directly point to reasons (and fixes) as the distance between compiling from sources to showing phpinfo() and then finally missing the extension is large.
Get the real error message first
One way to reduce the distance in trouble-shooting is to see if the extension can be loaded by PHP and if not, showing an error message.
A common test for that is to use the CLI SAPI (PHP on the commandlineDocs) as it allows to reduce and easier control the PHP runtime environment while being compatible with the extension.
To start PHP with the default configuration (no .ini files), loading only the single extension binary to test and showing the configuration information, run:
$ php -n -d extension=gmp.so -i
Excerpt from OptionsDocs, also there is php --help:
-n No php.ini file will be used
-d foo[=bar] Define INI entry foo with value 'bar'
-i PHP information
This should provoke an error (shown in the terminal on standard error) or show the extension loaded in the PHP information output (on standard output).
Alternatively, to reduce the output and only check for the error, execute an empty PHP statement with the -r command-line switch:
-r <code> Run PHP <code> without using script tags <?..?>
The example with the GMP extension in question:
$ php -n -d extension=gmp.so -r ';'
This will exit non-zero (exit status) if there is a problem loading the extension displaying and error message on standard error and would exit with zero status in case the extension could be loaded:
$ php -n -d extension=gmp.so -r ';'
PHP Warning: PHP Startup: Unable to load dynamic library 'gmp.so' (tried: /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so (dlopen(/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so, 9): no suitable image found. Did find:
/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so: mach-o, but wrong architecture
/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so: mach-o, but wrong architecture), /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so.so (dlopen(/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/gmp.so.so, 9): image not found)) in Unknown on line 0
$ echo $?
254
As the example shows, the error is already in "PHP Startup" which is the typical phase where PHP signals diagnosis messages loading extensions.
Dlopen 9: no suitable image found: mach-o, but wrong architecture
The error message above shows that a) PHP is first of all unable to load the extension (as a dynamic library, .so file, a shared object file, that is the compiled extension) and b) that it failed to load as no suitable image was found:
PHP Warning: PHP Startup: Unable to load dynamic library 'gmp.so' (tried: <path> (dlopen(<path>, 9): no suitable image found. Did find: <path>: mach-o, but wrong architecture ...), <path>
(dlopen(<path>.so, 9): image not found)) in Unknown on line 0
That means the file is available on disk (can be opened) but the image is not suitable, which means it does not match the architecture.
(there is some noise in the try for gmp.so.so that is done by php so one can pass -d extension=gmp without the extension to work directly, e.g. in a php-.ini to work on both *nix (.so) or windows (.dll). This part can be ignored, that is "image not found" as the file does not exists which is expected)
It must be the same architecture as PHP itself as PHP is already running and wants to load the binary extension - they need to fit.
To get the architecture of PHP, locate the PHP command:
$ which php
/Applications/MAMP/bin/php/php7.3.27/bin/php
This is the absolute path to the php binary. With it, it is now possible with the file(1) utility to obtain more information about it:
$ file /Applications/MAMP/bin/php/php7.3.27/bin/php
/Applications/MAMP/bin/php/php7.3.27/bin/php: Mach-O 64-bit executable x86_64
(or call $ file "$(which php)" for running both at once)
It shows the php binaries info incl. the x86_64 architecture at the end:
Mach-O 64-bit executable x86_64
As the shared object image to load (the compiled php extension gmp.so file) also needs to match it, the same file(1) utility can be used on the compiled extensions .so file in the same manner.
The comparison then should show the difference.
With this information at hand finally the extension can be compiled with the appropriate architecture.
Closing notes:
On Apple Silicon M1 I'm not specifically profound of compiling and its architectures and others can tell it better. From what I've seen you manged it by running brew with the arch(1) utility setting the architecture by arch -x86_64 <command> to x86_64. On Apple Silicon this may require more tooling, namely Rosetta.
It seems to be something common M1 users blog about (via Austen Cameron in Nov 2020) but this is entirely not my system.
From my own understanding it should be possible to set the architecture with compiler flags or on the configure line and thats normally it.
As brew has the information how to compile an extension on a system (the brew formula, here for gmp) it is perhaps most straight forward to go with it and run the install under the correct architecture.
With the caveat that you need to start brew in (?) the correct architecture with the arch(1) utility as well (and the brew install).

Related

CodeIgniter Error After Changing PHP from 5.6 to 7.0 on HostGator via SSH

So as the title describe, I am receiving this error right now on my CI after changing the PHP from 5.6 to 7.0. It works fine if I revert back to 5.6 but I need my server to be on 7.0.
A PHP Error was encountered
Severity: Core Warning
Message: PHP Startup: SourceGuardian: Unable to initialize module Module compiled with module API=20121212 PHP compiled with module API=20151012 These options need to match
Filename: Unknown
Line Number: 0
Backtrace:
From my 2013 blog post: https://delboy1978uk.wordpress.com/2013/10/30/manually-compiling-php-modules-successfully/
This look familiar?
PHP Warning: PHP Startup: memcached: Unable to initialize module
Module compiled with module API=20090626
PHP compiled with module API=20100525
These options need to match
I don’t know about you, but i like to be up to date! My PHP is on 5.5, and I had to install some modules. But sometimes, old versions can rear their ugly head, and cause all manner of grief. Package managers do a good job to take care of all this for you, but sometimes they just don’t work. Leaving you to compile yourself! So lets do it! I’m going to install memcached, and then the imagick libraries (now i know what i’m doing!)
I’m doing this on a CentOS 6 server, but as we are doing the old skool way of compiling etc, this should work on any other flavour of Linux, or indeed Mac OS X.
First step is to download your .tar.gz then unzip it with tar -zxvf file.tar.gz and change into the folder.
Bring up a web page displaying your servers php.ini. You are looking for the version of PHP API, and the extension_dir.
In your terminal, cd into the module source code folder, and type phpize.
If when you check the API versions , they are different from your php.ini, then an old version of php is being used in the terminal, and your module will not work! In this case, you need to get it to use the correct phpize.
type which phpize to find out where the offending file is. (mine was /usr/bin/phpize)
My PHP appeared to be in /usr/local, so I tried running /usr/local/phpize. The API’s matched. So then I did the following:
mv /usr/bin/phpize /usr/bin/phpize-old
ln -s /usr/local/bin/phpize /usr/bin/phpize
Half way there! We need to do the same for php-config
mv /usr/bin/php-config /usr/bin/php-config-old
ln -s /usr/local/bin/php-config /usr/bin/php-config
Now you have done that, installation should be trivial, and work as per loads of tutorial/instrruction pages on the web.
./configure
make
make install
Finally edit your php.ini and add ‘extension = memcached.so’ (or whatever module you compiled), and restart your apache server!
EDIT : you may need to run ‘phpize –clean’ if it is still compiling with the older stuff from within the modules source folder
Download latest SourceGuardian module, which support PHP 7.X:
https://www.sourceguardian.com/loaders/download.php

Issue getting mac to use brew php version

I had php installed and now I am trying to switch over to valet-plus to I can switch between php versions easy but I am running into some issues.
I have php71 and php 56 install but it seems like my computer keeps trying to use php from /usr/bin/local which is not where brew installs them.
When I do a php -v i get a warning "PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/extensions/no-debug-non-zts-20121212/mcrypt.so' - dlopen(/usr/lib/php/extensions/no-debug-non-zts-20121212/mcrypt.so, 9): image not found in Unknown on line 0"
It is correct that file is not there. I installed mcrypt from brew with brew install php71-mcrypt. If I look at the php.ini file where brew installed it that will show that file in the different path.
This is my .bash_profile and I source it and no errors show up but still old php location is there.
# Prefer US English and use UTF-8
export LC_ALL="en_US.UTF-8"
export LANG="en_US"
export PATH="/usr/local/mysql/bin:$PATH"
#export PATH="/usr/local/php5/bin:$PATH"
export PATH="/usr/local/Cellar/php71/7.1.5_17/bin:$PATH"
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*
I looked at about 30 different topics similar but none of those helped me out. I have unlinked and relinked php, reinstalled from source. I just need some direction on what is causing my apache to use the php location it is using and not allowing brew to switch it over.
Thanks

PHP, Apache: Unable to load dynamic library (even if there is one)

Today I have migrated my XAMPP's internals to 64bit:
Apache (from 32bit 2.4.25 to 64bit 2.4.27)
PHP (from 32bit 7.1.4 to 64bit 7.1.9)
I have downloaded each extension used before in 32bit, installed, configured (copy&paste mostly with path changes if needed) and generally everything "works".
-> % php --version
PHP 7.1.9 (cli) (built: Aug 30 2017 18:34:46) ( ZTS MSVC14 (Visual C++ 2015) x64 )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
But somehow I get PHP Startup: Unable to load dynamic library errors even if there are valid DLLs (most of them bundled in downloaded PHP package). These are curl, intl, ldap and imagick (the last one is installed by me). Paths are correct in php.ini (many other extensions are loaded properly from the same directory). This is what I get in php_error_log every time when I access page through Apache:
[22-Sep-2017 15:52:47 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'D:\Bin\XAMPP\7.0.9\php\ext\php_curl.dll' - The specified module could not be found.
in Unknown on line 0
[22-Sep-2017 15:52:47 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'D:\Bin\XAMPP\7.0.9\php\ext\php_intl.dll' - The specified module could not be found.
in Unknown on line 0
[22-Sep-2017 15:52:47 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'D:\Bin\XAMPP\7.0.9\php\ext\php_ldap.dll' - The specified module could not be found.
in Unknown on line 0
[22-Sep-2017 15:52:47 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'D:\Bin\XAMPP\7.0.9\php\ext\php_imagick.dll' - The specified module could not be found.
in Unknown on line 0
In CLI everything is fine (it's the same php.ini as for Apache):
-> % php -i | grep -n3 curl
175:curl
178-cURL Information => 7.55.0
-> % php -i | grep -n3 ldap
347:ldap
349-LDAP Support => enabled
350-RCS Version => $Id: 0779387e5f88edc656159d12b9302a053e82cc79 $
-> % php -i | grep -n3 intl
330:intl
332-Internationalization support => enabled
333-version => 1.1.0
335-ICU Data version => 57.1
but in Apache I have Attempted to call function "curl_init" ... error :(
Any ideas?
I had the same problem on Windows 10 and solved it by adding the php home directory to the system (NOT user!) PATH environment and rebooting the system.
When Apache is installed as a service it is run as a system user which means it does not see your user environment variables.
it's basically 404'ing the dll's. either the user that apache runs as, doesn't have permissions to read the folder D:\Bin\XAMPP\7.0.9\php\ext\ , or the folder doesn't exist. as for why it works in cli but not in apache, they're probably reading different php.ini's , but it could also be that php-cli runs as a different user account. to check that, run php -r 'phpinfo();' | grep -i username in cli, and a page with <?php phpinfo(); and look for "Enviorment" > "User" in apache phpinfo(); , the pages will also tell you if they're loading the same php.ini file.
and nothing of this has anything to do with programming, so i say again, this should be on serverfault.com or something, not stackoverflow.com
Check if your DLL's are in proper version. There is quite often difference between x64 and x86 version, also between ZTS and NON TREAD SAFE. For some reason instead of nice error message of ddls being incompatible you will only get information: cannot load extension.
Well, this is weird but the root problem of this issue was... using Apache as service. I can't explain why, but when running Apache as service these extensions could not be loaded, but when running without service, using only "Start" from XAMPP control center, all is working fine with the same config and directory/file structure.
I realized that when I wanted to back to my previous working versions and I linked 32bit versions again (I use apache and php symlinks in XAMPP installation dir). cURL was not loaded, but it was working before migrating to 64bit. So I started digging and experiment with service and after unregistering it started working correctly. So I thought it could be the case with 64bit too... And it was.
Now I can start Apache properly. There is still minor issue because XAMPP control panel doesn't show Apache as running after clicking "Start", but processes are there and is working. But most important is everything is OK under the hood.
I had the same problem. All extensions loaded except these two: amqp and pdo_sqlite:
PHP Warning: PHP Startup: Unable to load dynamic library 'pdo_sqlite' (tried: D:\\xampp74\\php\\ext\\pdo_sqlite (The specified module could not be found.), D:\\xampp74\\php\\ext\\php_pdo_sqlite.dll (The specified module could not be found.)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'amqp' (tried: D:\\xampp74\\php\\ext\\amqp (The specified module could not be found.), D:\\xampp74\\php\\ext\\php_amqp.dll (The specified module could not be found.)) in Unknown on line 0
One solution is so add the php path to your environmental variable PATH.
The real problem here is that although extension dlls live in xampp\php\ext, some extensions have additional files that are located in xampp\php. These additional dlls are the ones that can not be loaded if the php path is not added to your PATH.
If you do not want to add the PHP path to your PATH, the solution is to add the extra dll files to the xampp\apache\bin folder (copy, not move). In my case:
libsqlite3.dll for pdo_sqlite
rabbitmq.4.dll and rabbitmq.4.pdb for php_amqp
Or, if you start apache via a batch file, add the php path before starting apache:
SET PATH=%PATH%;d:\xampp74\php

Problems building and using mssql.so php extension, AMPPS server on MAC OSX

I think what I need to know is how to specify the build architecture when building .php extensions on OSX.
What are the likely architectures that I should try first, and how to specify them?
The details:
I am having trouble building a working mssql.so php extension for my server.
I have been using an AMPPS server on mac to serve php based websites, accessing MySQL databases.
Now I need to connect to an MSSQL database. The AMPPS php installation does not include the mssql extension so when I try to use mssql_connect() I get the following error.
Call to undefined function `mssql_connect()` in /Applications/AMPPS/www/test.php
I think I need to add mssql.so to the php/lib/extensions/ext folder and then add
extension=mssql.so
to my php.ini file.
To build mssql.so I have found a couple of online tutorials that both use Freetds:
http://lkrms.org/php-with-freetds-on-os-x-mavericks/#comment-82521
http://blog.benjaminwalters.net/?p=10
I used home brew to install autoconf:
brew instal autoconf
Then I downloaded and installed freetds:
./configure --prefix=/usr/local/freetds --sysconfdir=/usr/local/freetds/conf/freetds --disable-libiconv --disable-odbc
make
sudo make install
Freetds was installed at /usr/local/freetds. Then I downloaded php. I have tried this with all the versions available for download 5.6.2, 5.5.18, 5.4.32 and 5.3.29. 5.3.29 had a problem and I could not generate mssql.so.
All of the other versions successfuly produced mssql.so using the following method:
Unzip package in downloads folder
cd php-5.4.17/ext/mssql
phpize
./configure --with-php-config=/usr/bin/php-config --with-mssql=/usr/local/freetds
make
Then I copy the generated mssql.so to /Applications/AMPPS/php-5.4/lib/extensions/ext and add this to the php.ini file.
extension=mssql.so
I restart the apache server and view the error / log file which has the following error:
PHP Warning: PHP Startup: Unable to load dynamic library '/Applications/AMPPS/php-5.4/lib/extensions/ext/mssql.so' - dlopen(/Applications/AMPPS/php-5.4/lib/extensions/ext/mssql.so, 9): no suitable image found. Did find:\n\t/Applications/AMPPS/php-5.4/lib/extensions/ext/mssql.so: mach-o, but wrong architecture in Unknown on line 0
So it seems like I have built mssql.so for the wrong architecture?
I looked at the terminal output when I configure the "make" for mssql.so and found the following indicating the architecture it is being made for:
checking build system type... i386-apple-darwin13.1.0
checking host system type... i386-apple-darwin13.1.0
checking target system type... i386-apple-darwin13.1.0
So it looks like I made it for i386. This is where I start to get confused.
After make the terminal instructs me to run "make test", I do this and receive the following output:
=====================================================================
PHP : /usr/bin/php PHP_SAPI : cli PHP_VERSION : 5.4.24
ZEND_VERSION: 2.4.0 PHP_OS : Darwin - Darwin myMac13.1.0 Darwin
Kernel Version 13.1.0:
Thu Jan 16 19:40:37 PST 2014;
root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
INI actual : /Users/user/downloads/php-5.6.2/ext/mssql/tmp-php.ini More .INIs :
CWD : /Users/user/Downloads/php-5.6.2/ext/mssql Extra dirs :
VALGRIND:Notused
===================================================================TIME START 2014-10-26 11:53:50
=====================================================================
No tests were run. It does not say why no tests were run which is frustrating. It mentions x86_64 which is not i386.
I tried to check what architecture my system is to verify if it should be i386 or x86_64.
I did this with uname and arch as follows:
uname -p
i368
uname -m
x86_64
arch
i386
So my machine hardware is x86_64 (uname -m) but the processor architecture is i386 (uname -p) I don't understand how these can be different or what the implications of this are.
So have I built mssql.so for the wrong architecture or have I done something else wrong? If I have built it for the wrong architecture then how do I configure it to build for the correct one?
Many thanks for any help with this.

Compile PHP extension on 64bit debian to 32bit PHP installation

I am trying to compile a PHP extension for a 32 bit PHP installation on a 64 bit system. However, I get the following warning when restart apache:
Warning: PHP Startup: Unable to load dynamic library '/opt/lampp/lib/php/extensions/no-debug-non-zts-20090626/spotify.so' - /opt/lampp/lib/php/extensions/no-debug-non-zts-20090626/spotify.so: wrong ELF class: ELFCLASS64 in Unknown on line 0
I compile everything using this command:
/opt/lampp/bin/phpize; CFLAGS=-m32 CPPFLAGS=-m32 CCASFLAGS=-m32 ./configure --enable-spotify --with-php-config=/opt/lampp/bin/php-config; make && make install
The flags should make sure it compiles to 32bit. I have gcc-multilib and g++-multilib installed
When it is done compiling (this this log: http://pastebin.com/MqgGgyzv) i do the following command:
file /opt/lampp/lib/php/extensions/no-debug-non-zts-20090626/spotify.so
and it returns
/opt/lampp/lib/php/extensions/no-debug-non-zts-20090626/spotify.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
So it is clearly not compiling it correctly, but I don't see what I'm doing wrong.
You're compiling OK, but the linker is inadvertantly creating a 64-bit .so.
The solution is to include "-m32" in your LDFLAGS, too:
https://askubuntu.com/questions/85978/building-a-32-bit-app-in-64-bit-ubuntu

Categories