macos – Gmp PHP extension – MAMP PRO – Code Utility


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:

  1. Downloaded gmp with brew using brew install autoconf gmp
  2. Downloaded PHP (i’m using version 7.3.24) from source
  3. Copied Gmp directory to /Applications/MAMP/bin/php/php7.3.24/include/php/ext
  4. Entered that dir and launched phpize
  5. Launched ./configure --with-php-config=/Applications/MAMP/bin/php/php7.3.24/bin/php-config
  6. Launched make
  7. 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 (the file exist in this path /Applications/MAMP/bin/php/php7.3.24/include/php/ext/gmp/modules/

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, 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 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 -i
PHP Warning:  PHP Startup: Unable to load dynamic library '' (tried: /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/ (dlopen(/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/, 9): no suitable image found.  Did find:
    /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/ mach-o, but wrong architecture
    /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/ mach-o, but wrong architecture), /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/ (dlopen(/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/, 9): image not found)) in Unknown on line 0
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                    
[~]$ 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 -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 -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 -r ';'
PHP Warning:  PHP Startup: Unable to load dynamic library '' (tried: /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/ (dlopen(/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/, 9): no suitable image found.  Did find:
    /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/ mach-o, but wrong architecture
    /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/ mach-o, but wrong architecture), /Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/ (dlopen(/Applications/MAMP/bin/php/php7.3.27/lib/php/extensions/no-debug-non-zts-20180731/, 9): image not found)) in Unknown on line 0
$ echo $?

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 ‘’ (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 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

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 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).